wviewweather.com

mteel · Joined: 30 Jun 2005 Posts: 435 Location: Collinsville, TX

The DST change was almost handled properly by version 1.8.2. I will be investigating my log messages and the code over the next week or so to determine the fixes required, but here are the problems I've seen so far:

1) Once the time rolled back to 1 AM, each console polling interval, the VP reported an archive record available even though there really wasn't a new record, causing ARCREC to display multiple entries for each archive interval. This also caused the history data that the charts are based on to be updated erroneously (too often). This seems to be corrected when wview is restarted.

2) On my FreeBSD server, the cron job which kicks off the "adjkerntz" daemon did not run until 1:01 AM (after the time change), and wview expected the time zone to be correct as soon as the time had been rolled back by the system. This caused an incorrect GMT offset to be sent to the VP console at 1:00 AM (after the time change). It was corrected with the next wview console time synchronization which occurs hourly from the time wview is started. I will look into when adjkerntz is supposed to fire off and try to allow for it in future versions of wview.

Note: I will investigate the impact on the archive files soon and report back. Fundamentally, "Fall back" will have to "lose" an hour of data and "Spring Forward" will have a one hour gap... Unless someone has a better way of approaching these events.

If you observed any other problems relating to DST change, please post them here with new forum topics.

I will try to address all issues found. The problem is I don't have a secondary VP so testing is not really possible without hosing up my archive buffer in the VP data logger since I would have to set system time on the test server and the VP console to near the DST change dates/times. Hopefully I can correct these remaining issues without testing directly.

Mark