BST

[moelycrio]

So BST happened last night but what of Cumulus? My weather station runs at GMT so as to avoid the problem of missed/duplicate data. Cumulus has no records for 01:00 to 02:00 so must run on PC time. In october the opposite must apply where the data is duplicated. Both these scenarios cause report errors. Will cumulus 2 be more time aware by setting a flag BST GMT in data, or is this a design feature to be continued? Could it be an option ?

[steve]

It's quite hard to devise a scheme that works for all weather stations. For the VP it's not so bad as it timestamps entries in the logger, so there could simply be an option to run Cumulus at the station time setting instead of PC time. Other stations don't timestamp logger entries, so Cumulus has to try to work out their times based on the current time and work backwards. The same option could still be available, it just wouldn't work as nicely.

The plan is that Cumulus 2 will timestamp using UTC. I still haven't completely thought this through, as there would still be a need to map UTC onto local time, and there is no reliable way that I know of to determine whether a given date and time in the past is in daylight saving time or not (because the start and end times tend to change). So the log entry would need a flag. Easy enough to do in real time, as Windows knows whether or not you are currently in DST. But reading entries from the logger still requires the knowledge of whether the date and time in the past was in DST or not. I believe Microsoft did something in Visual Studio 2008 (which is what I'm using for Cumulus 2) which made 'historical DST lookup' easier, but I haven't had chance to look into it yet.

If anyone has any brilliant ideas about the best way for Cumulus 2 to handle timestamps, don't be shy, let's discuss them!

Steve

[steve]

I've just done a quick bit of research and come across the 'Olson Database', which contains all of the historical DST changes for all timezones, so it appears that this would be a possible solution, allowing Cumulus 2 to timestamp in UTC and still convert to local time for display/analysis purposes.

Steve

[beteljuice]

I don't know how you cope now, with the differing wx station formats

eg. My wx2300 has only just decided to update its (now BST) time signal, so If I hadn't been running my PC 24/7, presumeably once the wx 'log' had been interrogated, all the timestamps would be an hour out ?

I don't see how you can 'ask' the wx what TZ the initial timestamp is ?

[steve]

The Ws2300 doesn't timestamp its logger entries, so its clock doesn't matter. Cumulus would just use PC time and go back far enough to get the missing data. And get it wrong, of course, because it would go back an hour too far. As with the Fine Offset stations, there would be an hour of duplicated data.

Steve

[moelycrio]

Steve,
I've been trying to mull over this, I never realised it was so complicated until I considerd international time .
I'm used to the concept that the data file has a flag to define Daylight Saving Time or not, on each reading, but then I'm used to binary data files, and who cares about a extra bit per record? From the application level Olson would work, tag DST on write, on read check DST in Cumulus then alter record accordingly.
Realtime txt is another issue. Windows can cope very well converting UTC to local time, but with weather records, looking at a UK trend in US one would expect max temp some time in the afternoon not one of the many US time zones, would look strange if not, I believe american DST do not follow EU DST another issue.
In my case I FTP realtime.txt to my ISP where I load the data into a mysql table, I would sooner use a stored procedure to sort out time issues and produce data to UK GMT/DST leaving the PC DST time free. To do this it would be easier GMT, if there was a DST flag in realtime.txt as well. But I except that most users wouldn't like this complication and prefer the simplicity of realtime=current time.
Trying to keep it simple is difficult, perhaps why people find it simple just to keep data to GMT, I notice this forum states "all times are UTC"

[Gina]

DST (alias BST in the UK) causes all sorts of headaches And having to change lots of clocks is only one of them (unless you have radio controlled clocks). This is a very awkward question with weather data and reports. International time is another problem as has been mentioned. This whole time thing is clearly something that needs a lot of thought. My first thoughts on the matter suggest local time but without DST would be the best compromise to avoid missing or duplicated data. But when stations don't support this in their data, it's a real problem. Not so bad when the PC is left running 24/7 and can process the WS data in real time. I shall give this more thought...

EDIT... Looks like I have a problem with my banner script - I'll check that out later.