> 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 _______________________________________________ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
