the final second before standard time daylight savings time transitions
Hello, Is there any official documentation on the time zone for March 13 2016 in New York City, when the clock says 1:59:59.99991000 ? My guess would be that it is EST or -04:00 offset, but I cannot find anything that discussed the fractions of the last second. We store fractions of seconds, and we need to be able to convert to a particular offset. Thanks for your work and your consideration. P.S. I have enjoyed the notes in the time zone rules. Most Respectfully, Mark Inman Army Analytics Group Email: mark.h.inman2.civ@mail.mil Personal Work Phone: 707-863-7150 Personal Cell Phone: 925-324-9864 Personal Cell Text: 9253249864@vtext.com
Inman, Mark H CIV USARMY HQDA (US) wrote:
Is there any official documentation on the time zone for March 13 2016 in New York City, when the clock says 1:59:59.99991000 ?
I don't know about "official", but in practice digital clocks jump from 01:59:59.99999...9 EST to 03:00:00 EDT. You can use as many 9s as you want, as long as it's a finite number of 9s. This is baked into the POSIX API, e.g., the nanoseconds component of struct timespec has nine 9s. This reminds me of the confusion at midnight. Does midnight belong to the previous day, to the next day, to both, or to neither? Traditionally, it was ambiguous. Nowadays with digital clocks midnight is invariably 00:00 at the start of the next day.
I'll add that while this is the best practice, and is indeed what is implemented in the vast majority of hardware and software I've seen, I've also seen implementations that either advance from 1:59, to 2:00, to 3:01 - or go from 1:59 briefly to 2:00 and then some fraction of a second later go to 3:00. Both of which I would consider to be bugs. This is especially problematic in the fall-back direction when the transition is at or near midnight. Instead of correctly going from 23:59 to 23:00, if one erroneously hits 00:00 before going back, then that means the DATE has changed as well - and then changes back again a split second later. This can have nasty consequences if there are events triggered to fire right at midnight. IIRC, there was a bug in some older versions of Windows (can't recall which) related to this. To avoid a possible regression, the Windows data has all 00:00 fall-back transitions defined as 23:59:59.999 of the prior day. -Matt ________________________________ From: tz-bounces@iana.org <tz-bounces@iana.org> on behalf of Paul Eggert <eggert@cs.ucla.edu> Sent: Wednesday, June 15, 2016 11:47 AM To: Inman, Mark H CIV USARMY HQDA (US); Time zone mailing list Subject: Re: [tz] the final second before standard time daylight savings time transitions Inman, Mark H CIV USARMY HQDA (US) wrote:
Is there any official documentation on the time zone for March 13 2016 in New York City, when the clock says 1:59:59.99991000 ?
I don't know about "official", but in practice digital clocks jump from 01:59:59.99999...9 EST to 03:00:00 EDT. You can use as many 9s as you want, as long as it's a finite number of 9s. This is baked into the POSIX API, e.g., the nanoseconds component of struct timespec has nine 9s. This reminds me of the confusion at midnight. Does midnight belong to the previous day, to the next day, to both, or to neither? Traditionally, it was ambiguous. Nowadays with digital clocks midnight is invariably 00:00 at the start of the next day.
participants (3)
-
Inman, Mark H CIV USARMY HQDA (US) -
Matt Johnson -
Paul Eggert