Daylight savings time change

f4phlyer · Post by **f4phlyer** » Sun 01 Nov 2015 10:39 pm

Don't know if this would be considered a bug or what, and I'm not sure if it's been covered before but last nights time change for 'Daylight Savings Time' was rather "graphically" demonstrated. I don't recall what C1 but I was wondering if there is an easy more elegant solution.

time change.png

Pic a little fuzzy but the plot retraces itself at 2:00AM.

Post by **steve** » Mon 02 Nov 2015 8:08 am

MX does exactly the same as Cumulus 1, i.e. nothing. I don't propose to change this. There is no workable solution that I'm aware of; if there was, the weather station manufacturers would have adopted it. Even if Cumulus timestamped its data using a non-DST timezone (or UTC) the graph would look the same when mapped on to local time. The only real solution is to run your station on a fixed timezone all the time. This is effectively what professional meteorologists in the UK do, where all reporting is done in GMT/UTC, year round.

Nykita · Post by **Nykita** » Mon 02 Nov 2015 6:48 pm

Quote from original post: Pic a little fuzzy but the plot retraces itself at 2:00AM.

If you think about it, So did the clock!!!!!

Maybe I'm just being a grouch.... But, a goofy looking graph, at a time change that we all know happened, no big deal.... If someone viewing the graph is too ignorant to put the graph together with a darn calendar, then the problem is theirs!!!

My graph looked much like the one posted above, I said " That's cute" and went on with my day..

Sorry for the rant!!!!

logjam · Post by **logjam** » Mon 02 Nov 2015 10:56 pm

I'm going to crow a little bit over this, which makes a change for me.

I'm not able to use the json files to make graphs so I make use of the webtag data with the Highcharts. Since the data is relative to the present time and not absolute, I get no problems with the graphs when the clocks change. It is good to know that sometimes a problem can occasionally lead to an advantage!

Post by **steve** » Tue 03 Nov 2015 8:10 am

That isn't really a solution though. Presumably you have an hour of data missing from your graphs somewhere? So you do have a problem with the graphs - just a different one.

logjam · Post by **logjam** » Tue 03 Nov 2015 9:30 am

It seems my crowing was a little premature.

My 'last 24 hours' graphs use the 'Recent History' array. I just assumed that Cumulus squirreled away the data in that array and shifted the data on irrespective of any time change. From what you are saying, I suppose that <#RecentOutsideTemp d=1 h=1 m=1>, for instance is referring to the current time stamp, and not the relative position of data in the array. Certainly the graphs looked OK, but perhaps the data didn't change significantly during that hour.

Post by **steve** » Tue 03 Nov 2015 10:09 am

Recent History uses an SQL database, keyed on the timestamp (using the current computer clock time). Once a minute, it adds the current set of readings to the database. A duplicate timestamp (as will happen for an hour when the clocks go back) will cause the previous (DST) entry to be overwritten.

When it's retrieving an entry for a web tag, it works out how many minutes the three parameters are specifying in total, and subtracts that number of minutes from the current time, and extracts the entry corresponding to the calculated timestamp.

But my point is really that however you store your data, you can't have a graph that has all of the data and doesn't have a 'glitch', unless the graph is 'DST-aware' and can have an X-Axis which repeats an hour's worth of times. Or you ignore DST changes and have all of your data timestamped with one consistent set of timestamps.

I wonder how many times this has been discussed on the forum? Once or twice a year since it started, I guess

logjam · Post by **logjam** » Tue 03 Nov 2015 5:08 pm

steve wrote:A duplicate timestamp (as will happen for an hour when the clocks go back) will cause the previous (DST) entry to be overwritten.

It's one of those things that becomes obvious when it is explained - thanks!

At the risk of prolonging a understandably hackneyed topic,

it seems to me that having CumulusMX running on a dedicated machine like the Pi, means that the weather data can indeed be set to UT all year round with no problems. Disabling 'summer time' on my multi-purpose laptop, with the old Cumulus, would have caused far too many problems to contemplate. As an amateur astronomer my observatory clock is set to UT all year around, and all my logs are in UT, so it is nothing new to me. Is there a simple raspbian command that would stop the Pi from going into summer time?

Post by **steve** » Tue 03 Nov 2015 5:18 pm

I think it's a case of using one of the timezone files that doesn't have DST changes, e.g. Etc/GMT

f4phlyer · Post by **f4phlyer** » Sat 07 Nov 2015 4:28 am

Steve, of course.

The GMT utilization is a good thought provocation.

BTW, you mention the "recent graphs" use the SQL db. I've looked for the code item that lengthens the time of the graph to look more like Mark's graphs with no luck. Am I missing something obvious?

Steve

Post by **steve** » Sat 07 Nov 2015 7:59 am

The graphs don't use an SQL database, the 'Recent History' web tags do. Those go back a week, and you can't currently change that. If you want to change the period for the standard graphs, the settings are in the 'Graphs' section on the Station Settings screen.

Cumulus Support