Changing to BST Clocks move forward an hour

[Phil Green]

Hi
The same thing happens every year when the clocks move forward an hour at the start on British Summertime.
My Weewx on a Pi with data from my VantageVue stalls at 2am the time of the change.
Solution: The Pi time is correct in BST after the change. I have to stop Weewx then do a wee_device --clear-memory, then start Weewx again. I loose data from 2am until the time of restart.
This happens when the clocks go back too.
Any automatic solution?
Regards
Phil.

[Devonian]

Ditto for me as well.

I'm on ver 3

restart doesn't fix it, excerpt from syslog

Mar 26 08:32:53 debian8vm weewx[1392]: vantage: gentle wake up of console successful

Mar 26 08:32:53 debian8vm weewx[1392]: engine: Clock error is -0.16 seconds (positive is fast)

Mar 26 08:32:53 debian8vm weewx[1392]: vantage: Getting archive packets since 2017-03-26 02:00:00 BST (1490490000)

Mar 26 08:32:53 debian8vm weewx[1392]: vantage: gentle wake up of console successful

Mar 26 08:32:55 debian8vm weewx[1392]: vantage: Retrieving 513 page(s); starting index= 1

Mar 26 08:32:55 debian8vm weewx[1392]: vantage: DMPAFT complete: page timestamp 2017-03-17 10:15:00 GMT (1489745700) less than final timestamp 2017-03-26 02:00:00 BST (1490490000)

Mar 26 08:32:55 debian8vm weewx[1392]: vantage: Catch up complete.

Mar 26 08:32:55 debian8vm weewx[1392]: engine: Starting main packet loop.

Mar 26 08:32:55 debian8vm weewx[1392]: vantage: gentle wake up of console successful

Mar 26 08:32:55 debian8vm weewx[1392]: vantage: Requesting 200 LOOP packets.

Mar 26 08:32:55 debian8vm weewx[1392]: vantage: gentle wake up of console successful

Odd timestamp but that is what it spits out.

Fixed with clear-memory as above.

Nigel

[gearoid]

Me too.

I've opened this issue on github

https://github.com/weewx/weewx/issues/247

[Luc Heijst]

It is a known problem. It happens only at summertime start. The cure is to let the vantage driver not store the first hour after start summertime to the database.
I could Tom not persuit to implement it in the driver. The other solution is to clear the loggers memory.
Luc

[Mike Revitt]

I used to fix it with these commands and this resulted in no loss of data

https://www.cougar.eu.com/useful-guides/weewx-guides/managing-the-change-to.html

But the dump command no longer works so looking for an alternative

[Luc Heijst]

Just thinking...

A brute force fix might be to open the weewx database and change the time stamp of the newest record. set dateTime to dateTime +3600. Then restart the vantage driver (restart weewx).

Luc

[Mike Revitt]

I think I have found the fix that updates the database without the loss of data

webmail:Weewx Mike$ sudo launchctl unload /Library/LaunchDaemons/com.weewx.weewxd.plist 

Password:

webmail:Weewx Mike$ pwd

/Groups/revitt/WebSites/Weewx

webmail:Weewx Mike$ /Groups/revitt/WebSites/Weewx/bin/wee_device /Groups/revitt/WebSites/Weewx/weewx.conf --dump

Using configuration file /Groups/revitt/WebSites/Weewx/weewx.conf

Using Vantage driver version 3.0.7 (weewx.drivers.vantage)

Proceeding will dump all data in the logger.

Are you sure you want to proceed (y/n)? y

Starting dump ...

Records processed: 2560; Timestamp: 2017-03-22 07:20:00 GMT (1490167200)

Finished dump. 2560 records added

webmail:Weewx Mike$ sudo launchctl load /Library/LaunchDaemons/com.weewx.weewxd.plist

Password:

webmail:Weewx Mike$ 

I will know for sure in 3 minutes when the Website next refreshes

[Mike Revitt]

And I can confirm all fixed

https://www.cougar.eu.com/Weewx/MountWeather/index.html

[Luc Heijst]

Hi Mike,

Nice solution! 

The problem is as follows. Because the vantage logger has neither UTC time stamps nor DST flags it can't make a distiction between a time stamp in wintertime and in summertime.

The vantage driver hast to convert the logger time stamp to UTC and makes an assumption about being summertime or not. This will be based upon the server time stamp and DST flag

At the start of a new archive interval the vantage driver asks the logger for all records newer than its last registrated record in the database. Because of the miscommunication summer-wintertime time stamps the logger thinks it has no such record in its database and offers the vantage driver all records starting with the eldest record. (Note: the logger thinks the vantage driver asks for time stamps 02:00, 02:05, which are not in the loggers memory because it has instead time stamps of 03:00, 03:05 etc)

On its turn the vantage driver takes a conclusion that no record has to be retrieved and no record is stored in the weewx database.

The next archive period the same story starts all over. This will repeat until all logger data will be overwritten (this will take 4 days with 5-minute registrations).  

We have found the following solutions so far:

• clear the logger memory
  
• wait until the logger memory has overwritten all data with time stamps before start summertime
• don't let the vantage driver store the logger data between start summertime and start summertime + 3600 s
• dump all logger data to the weewx database
• (not tested and NOT reccommended) change the time stamp of the newest weewx record to time stamp+3600

Luc

[Mike Revitt]

Great Luc,

Nice Explanation.

I have now updated my guide based on what I found this morning

https://www.cougar.eu.com/useful-guides/weewx-guides/managing-the-change-to.html