[time-nuts] When does NIST change to DST?

Tom Van Baak tvb at LeapSecond.com
Tue Mar 15 20:22:25 EDT 2016


> I'm still not certain when exactly the DST bits are first flipped by WWVB, which I'd be curious to know.

Hi Hank,

It may be confusing to use the word "flipped" here -- because the algorithm is more complicated than a light switch or binary "DST or not DST". There are 2-bits and 4 states total. It's awkward, but necessary.

The succinct explanation comes from http://tf.nist.gov/general/pdf/1383.pdf where it says:

> Daylight saving time (DST) and standard time (ST) information is transmitted at seconds
> 57 and 58. When ST is in effect, bits 57 and 58 are set to 0. When DST is in effect, bits
> 57 and 58 are set to 1. On the day of a change from ST to DST bit 57 changes from 0 to
> 1 at 0000 UTC, and bit 58 changes from 0 to 1 exactly 24 hours later. On the day of a
> change from DST back to ST bit 57 changes from 1 to 0 at 0000 UTC, and bit 58 changes
> from 1 to 0 exactly 24 hours later.

A verbose explanation comes from https://en.wikipedia.org/wiki/WWVB where it says:

> 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. 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:00Z, the end of the current UTC day. Bit 58 is set if DST was in effect
> at 00:00Z, the beginning of the current UTC day.

So this should answer your question about when and how the DST state bits are managed. It's not that simple, is it? This helps explain why some RC clocks don't get it quite right. Imagine also the boundary cases where you powered-up a new RC clock a few minutes before 0h UTC or 2 AM local last Sunday.

To make matters more interesting, the enhanced WWVB format includes a completely different way to encode DST:

http://tf.nist.gov/general/pdf/2591.pdf

http://tf.nist.gov/general/pdf/2719.pdf

Finally, add these to your WWVB DST reading list:

http://tf.nist.gov/general/pdf/2422.pdf

http://www.nist.gov/pml/div688/grp40/wwvb.cfm

https://answers.yahoo.com/question/index?qid=20110313121231AA6PIb0

https://www.febo.com/pipermail/time-nuts/2007-March/024744.html 

Just hope we don't ever, some distant year in the future, have a leap second and a DST change on Sunday 2/29 ;-)

/tvb



More information about the time-nuts mailing list