Cumulus Support

Another in my growing list of silly questions, what happens when daylight savings rolls around?

I always search before asking though

I understand Cumulus uses the PC clock, so my pc clock went forward an hour a week or two ago (we are going into summer). Does the pc clock operate some form of 'relative' time that excludes daylight saving? Otherwise Cumulus will backfill the data with an hours worth?

No, wait, does it just continue on as if nothing has happened because 'time keeps on slipping'?

And what happens when daylight savings comes off/going back to normal time?

On the hardware side, I set the non daylight savings time to -1 hour on the display, as I purchased and setup my unit during daylight savings last year. So for daylight savings I just put the time zone back to zero.

Cumulus timestamps 'live' data at the current Windows clock time. With logger data from a Fine Offset station (which isn't timestamped), it works backwards from the current time at start up to try to generate correct timestamps.

So basically, at the start of DST you get an apparent gap of 1 hour in the logs, the precise timing of which depends on when Cumulus was running. Similarly, you get an apparent hour of duplicate timestamps at the end of DST.

Wow, you beat me to it Steve, sorry to make you repeat yourself

Was going to post:

"Sorry, found Steve's answer here https://cumulus.hosiene.co.uk/viewtopic.p ... ing#p12690

I only searched on the Fine offset forum "

Just a quick thought, I'm a total bumkin regarding software, but have you thought about somehow getting Cumulus to recognise its own stamp for each logging entry, and tying it somehow to a incremental measure coming out of the logger?

I'm not sure which value, I don't actually think there might be any, but I guess the idea is that Cumulus builds from the bottom up. Like if it recognises/matches the last entry in cumulus log and matches it to the line of data in the Fine Offset logger, then imports every record after that?

I don't know, thinking out loud.

I suppose then it would still have a problem as there would be 25hours of data in one day a year and 23 hours in one other, which it couldn't include on the graphs.

In any case, one hour of data is insignificant. A lot of hard work for little gain I guess.

Thanks again for the great software Steve.

It's quite hard to do anything sensible. Cumulus 2 logs data using UTC, so there's no issue of repeated/missing timestamps. But you still have the issue of how you display the data using local time.

To minimise the effect in Cumulus 1, you would keep it running over the time change. While this doesn't stop the apparent gap and apparent duplication, it does at least guarantee that no actual data can be missed or repeated, and the affected hours appear at fixed times in the logs.

If you are logging, in C2, with UTC, are you also logging the local offset? eg for me in winter this would be +10; in summer (like now) with DST in place, this would be +11.

If not would it be worth logging this if possible as we would then know for certain when we are and are not under DST conditions?

serowe wrote:If you are logging, in C2, with UTC, are you also logging the local offset?

No, I don't need it because .NET handles the conversion for me. But it would be easy enough to add a field to the database so that someone could do the conversion for themselves.

Not sure I understand your response - I realise you know what is happening (wrt to DST) but if a user wants to generate graphs, data etc - how will they know if DST is in play or not? After all, on a Windows machine, we can tell it to ignore DST if we want to - how would that affect the data C2 stores and uses?

It depends on how they want to use the data to draw the graphs. If they want to use the database directly (bypassing Cumulus), they will either need to use something which can convert timestamps from UTC to local (like .NET), or they will need to use this new field which you have proposed, to do the conversion.

If they don't use the database directly but get Cumulus to export it, then Cumulus will convert the timestamps to local time.

OK I think I understand you now.

From your POV then - is there any downside to the DB holding a flag to indicate whether DST is in operation or not? (apart from it being present on each record that is ). I'm thinking of something like DAV's and my scripts accessing the data from a PHP perspective and not .NET.

serowe wrote:From your POV then - is there any downside to the DB holding a flag to indicate whether DST is in operation or not?

I don't think so; and I can think of some possible advantages... DST start and end times sometimes (but rarely) change. .NET isn't clever enough to know historical changeover times, so there is a small possibility that it could do the conversion incorrectly for 'old' dates if the DST dates have changed. I've been musing over what to do about this; there are various ways around it, but storing the offset at the time the entry is made is possibly the easiest. It's still not 100% safe, though.

As background info - the Eastern States of Australia altered their start and end of DST times in 2009 - we used to start at the end of Oct and finish at the end of Mar but last year we were brought into line with Tasmania by starting at the beg of Oct and ending at the end of Apr (aused some confusion but we just blamed it on the Tasmanians!).

Also WA experimented with DST but I believe rejected its continued implementation from this year in parts of WA.

Yeah, last yeah NZ extended DST by I think a week either end. Shouldn't happen too often though.
Apparently the farmers like it for some reason, maybe the cows know they have to come to the shed an hour earlier?
Glad I didn't start another dead thread..

Has nothing to do with the cows - there's a secret society making fade-resistant curtains in UnZud for sale to the Aussies

Animals know nothing about our fad for messing about with the clocks, they just carry on with the old times. In fact farmers here don't like the clocks changed! In this area it's the tourist industry that are pressing for Double Summer Time - WE DON'T WANT IT!!!