WWVB daylight davings time

[t11s]

It works to simulate WWVB to set a Five Senses talking watch, thanks!

But it does not appear to handle daylight savings time in the US.

[hzeller]

Is your Raspberry Pi set to your local timezone ? I think the default Raspbian is set to UTC.

The code should handle it, but I don't have a WWVB clock to check.

[icb-]

It's only able to signal that DST is in effect (seconds 57 and 58 both set), or that it isn't in effect (seconds 57 and 58 both cleared). It can't signal the change days. I think second 58 is being calculated correctly, but second 57 should be set based on the the tm_isdst flag for a timestamp 1 day in the future.

Many clocks will handle the current code fine, because they're already keeping track of the DST flag to handle missed sync windows, but it's far from guaranteed.

https://github.com/hzeller/txtempus/blob/d78e553557621d75d6a7eda89ac76cd82228a598/wwvb-source.cc#L28-L45

Per the Wikipedia article on WWVB:

The DST status bits indicate United States daylight saving time rules. The bits are updated daily during the minute starting at 00:00 UTC. The first DST bit, transmitted at 57 seconds past the minute, changes at the beginning of the UTC day that DST comes into effect or ends. The other DST bit, at second 58, changes 24 hours later (after the DST change). Therefore, if the DST bits differ, DST is changing at 02:00 local time during the current UTC day. Before the next 02:00 local time after that, the bits will be the same.

Each change in the DST bits will first be received in the mainland United States between 16:00 PST and 20:00 EDT, depending on the local time zone and on whether DST is about to begin or end. A receiver in the Eastern time zone (UTC−5) must, therefore, correctly receive the "DST is changing" indication within a seven-hour period before DST begins, and six hours before DST ends, if it is to change the local time display at the correct time. Therefore, receivers in the Central, Mountain, and Pacific time zones have one, two, and three more hours of advance notice, respectively.

It is up to the receiving clock to apply the change at the next 02:00 local time if it notices the bits differ. If the receiving clock happens not to receive an update between 00:00 UTC and 02:00 local time the day of the change, it should apply the DST change on the next update after that.

An equivalent definition of the DST status bits is that bit 57 is set if DST will be in effect at 24:00 Z, the end of the current UTC day. Bit 58 is set if DST was in effect at 00:00 Z, the beginning of the current UTC day.

[hzeller]

ah, ok, so that is my TODO about the announcement bits. I think I assumed no clock would be interested in the tomorrow state.

Would you like to send a pull request to fix that ?

[hzeller]

@t11s The patch by @icb- might fix your issue, but we only know for sure if you could test it with your clock.

[t11s]

Between updating the Raspberry Pi timezone and fetching the new code, it seems to work fine now, thanks!

[kkingsto]

Pi Zero W has it's time zone set to New York. Only my clock there is a switch for DST which was set on. This morning, the clock did NOT go back one hour. Ended up changing the DST switch off and ran TXTEMPUS. Time is correct.

Question: What should the pi be set to UTC or my local timezone? And the DST switch on the clock?

[hzeller]

Txtempus sends the DST information according to your local timezone, so having that set on the Raspberry Pi is correct. The state of DST is transmitted with txtempus, so this is how your clock knows how to react.

I suspect the switch on your clock is to override the DST/standard time information (i.e. ignore), thus it just kept showing DST even when the time was switched back to standard time. (this is the first time I hear about a DST switch on a clock, but that is what I assume from the symptoms).

So to show the correct time:

• Run the txtempus Raspberry Pi on your local timezone (you did that already).
• Switch off the DST switch (which you do now)