Doing historical catch-up which includes the daylight savings time change

[PaulMy]

Running C1, MX with WifiLogger, MX with WLL

C1 and MX with WLL did the time change in the expected way; after 01:55 to starts again at 01:00. 120 entries from 00:00 to 09:00.

MX with WifiLogger live likely did the same, BUT it lost connection and didn't log from about 02:00 to 08:00 (AWEKAS sent an email). So as to have a full data I restored from the midnight daily backup (unfortunately I didn't check the logging before doing the restore). That went well until I checked the log for the time change and found it had 5 minute logging from 00:00 up to current time, no repeat of 01:00 to 01:55. Doing a count of 5-minute logs from 00:00 to 09:00 this had 108 entries while it should have had 120 with the time change hour. Where did the second 01:00 - 01:55 logs go? or is it the first 01:00 to 01:55 that is missing?

Enjoy,
Paul

[mcrossley]

I think there are a couple of questions in there.

1. Does the logger have the duplicated entries?

2. Does catch-up cope with the time change?

I don't know the answer to either, but I can dig into 2...

Can you post the log file anyway, there may be something useful in there.

[PaulMy]

I had forgotten to check MXdiags... Attached is one covering the original from day rollover to when I stopped it. The second is from a CMX restart and using the data backup from the midnight rollover.

I wasn't able to see anything on the time change but see that there was a

Code: Select all

2022-11-06 01:57:00.298 *** Data input appears to have stopped

around that time, and until 08:08 which matches the period that AWEKAS data was not sent.

This CMX with WiFilogger is set with a 20 second disconnect period, and that allows WiFiLogger to upload to WL.com, and all the other weather services. This does cause periodic Data input appears to have stopped messages, but generally works ok.

Very possible the missing logs during the catch-up are unique to my setup.

Enjoy,
Paul

[mcrossley]

Thanks for the log files Paul, which are helpful.

The Davis logger does not provide UTC timestamp, just the local date/time encoded into two integers.

The log file shows that the logger entries proceed up to 01:55, the next entry being 01:00 and it then increments from there.

So all the data is being recorded, but unfortunately CMX sees the clock going backwards as an error (it does sometimes happen with corrupt logger data) and ignores the duplicated time entries. The hours data with duplicate time being dumped.

With no UTC value, there is no straightforward way of determining if say 01:15 is DST time or a standard time

It would mean every entry would have to be checked against the DST flag, and if the logger time reverts during the processing checking if the DST would have been set for next entry and forcing DST on or off in the timestamp interpretation.

The WLL does not have this problem because it uses UTC timestamps for the data.

[PaulMy]

Thanks Mark.
Just another thing to be aware of; try to avoid using catch-up that includes a DST change

Enjoy,
Paul