Date error in the diary.

[sfws]

Mark, I noticed (checking everything just before my 10am BST rollover to a new month this morning) that the date selector in my MX weather diary editor was highlighting tomorrow, instead of current date. I installed your new JavaScript file from this thread onto my RPi, and the date selector seems correct now (but it is after rollover, so I need to check again early tomorrow EDIT: Now it is next day, confirm that the new script pre-selects current calendar day, does permit selection of meteorological date (previous date) or any earlier date, but does not permit selection of tomorrow or any dates in future.).

As I have posted before, my Cumulus.ini contains SnowDepthHour=0 because I want snow to be assigned to calendar days, and I did check that (before rollover) the web tags were correctly reporting the right calendar day, so there was no error in the C# code.

[sfws]

Another reason not to use DST for weather data collection. It's a bad idea

I'm not sure when you first started using Cumulus, Niall, so you may not have experienced this. Anyway, when Steve Loft produced Cumulus 2, he designed it to store all the data in all log files (.txt and .ini) using UTC, because he thought that would avoid DST problems experienced by some of the original Cumulus (1) users.

Cumulus 2 had to be abandoned, this was for various reasons, mostly connected with Steve Loft admitting he was finding writing in C# hard, but using UTC proved to be a problem for some non-UK users of his software.

[freddie]

Another reason not to use DST for weather data collection. It's a bad idea

I'm not sure when you first started using Cumulus, Niall, so you may not have experienced this. Anyway, when Steve Loft produced Cumulus 2, he designed it to store all the data in all log files (.txt and .ini) using UTC, because he thought that would avoid DST problems experienced by some of the original Cumulus (1) users.

Cumulus 2 had to be abandoned, this was for various reasons, mostly connected with Steve Loft admitting he was finding writing in C# hard, but using UTC proved to be a problem for some non-UK users of his software.

I started using Cumulus in Jan 2010. I did give Cumulus 2 a try, which had the side effect of introducing me to Virtual VP. I don't recall the problems that overseas users had with UTC - but to hear of it doesn't surprise me.

I think users should store data under whatever time zone is most appropriate for them. What I disagree with is the two effective changes of time zone that occur when clocks are changed. This means that in March (or whenever the clocks go forward in the southern hemisphere) you get a one hour "hole" in your records. At the other end of the year you have an hour of duplicate records. I understand perfectly the wish to display the data according to the local time zone, but that can be done (relatively easily) without changing the recording time zone.