[PROPOSED] zic -r is incompatible with rolling leaps
* NEWS, zic.8: Mention this. * zic.c (leapadd): Report an error if the user tries it. --- NEWS | 3 +++ zic.8 | 3 +++ zic.c | 4 ++++ 3 files changed, 10 insertions(+) diff --git a/NEWS b/NEWS index 1b5535a..62a7ba2 100644 --- a/NEWS +++ b/NEWS @@ -137,6 +137,9 @@ Unreleased, experimental changes last time transition disagreed with the TZ string, contrary to Internet RFC 8563 section 3.3. + zic -r now reports an error if given rolling leap seconds, as this + usage has never generally worked and is evidently unused. + zic now generates a POSIX-conforming TZ string for TZif files where all-year DST is predicted for the indefinite future. For example, for all-year Eastern Daylight Time, zic now generates diff --git a/zic.8 b/zic.8 index b77841b..3023ebe 100644 --- a/zic.8 +++ b/zic.8 @@ -709,6 +709,9 @@ or .q "Rolling" if the leap second time given by the other fields should be interpreted as local (wall clock) time. +(Rolling leap seconds are not supported if the +.B \*-r +option is used.) .PP The expiration line, if present, has the form: .nf diff --git a/zic.c b/zic.c index e2a7e13..b06ef66 100644 --- a/zic.c +++ b/zic.c @@ -3144,6 +3144,10 @@ leapadd(zic_t t, int correction, int rolling) error(_("too many leap seconds")); exit(EXIT_FAILURE); } + if (rolling && (lo_time != min_time || hi_time != max_time)) { + error(_("Rolling leap seconds not supported with -r")); + exit(EXIT_FAILURE); + } for (i = 0; i < leapcnt; ++i) if (t <= trans[i]) break; -- 2.30.2
Rolling leap seconds were meant to accommodate the New York Times Square ball drop; at least in some leap-second years, there'd be a "3...2...1...leap...Happy New Year" countdown, placing the leap second at midnight New York time rather than midnight London time. @dashdashado On Sun, Sep 12, 2021 at 9:43 PM Paul Eggert via tz <tz@iana.org> wrote:
* NEWS, zic.8: Mention this. * zic.c (leapadd): Report an error if the user tries it. --- NEWS | 3 +++ zic.8 | 3 +++ zic.c | 4 ++++ 3 files changed, 10 insertions(+)
diff --git a/NEWS b/NEWS index 1b5535a..62a7ba2 100644 --- a/NEWS +++ b/NEWS @@ -137,6 +137,9 @@ Unreleased, experimental changes last time transition disagreed with the TZ string, contrary to Internet RFC 8563 section 3.3.
+ zic -r now reports an error if given rolling leap seconds, as this + usage has never generally worked and is evidently unused. + zic now generates a POSIX-conforming TZ string for TZif files where all-year DST is predicted for the indefinite future. For example, for all-year Eastern Daylight Time, zic now generates diff --git a/zic.8 b/zic.8 index b77841b..3023ebe 100644 --- a/zic.8 +++ b/zic.8 @@ -709,6 +709,9 @@ or .q "Rolling" if the leap second time given by the other fields should be interpreted as local (wall clock) time. +(Rolling leap seconds are not supported if the +.B \*-r +option is used.) .PP The expiration line, if present, has the form: .nf diff --git a/zic.c b/zic.c index e2a7e13..b06ef66 100644 --- a/zic.c +++ b/zic.c @@ -3144,6 +3144,10 @@ leapadd(zic_t t, int correction, int rolling) error(_("too many leap seconds")); exit(EXIT_FAILURE); } + if (rolling && (lo_time != min_time || hi_time != max_time)) { + error(_("Rolling leap seconds not supported with -r")); + exit(EXIT_FAILURE); + } for (i = 0; i < leapcnt; ++i) if (t <= trans[i]) break; -- 2.30.2
Thanks for the background. I checked videos of Times Square ball drops for New Years 2016 and 2017, and they didn't shout out or display leap seconds. Perhaps computerized stationary leaps have overcome old Times Square traditions? Anyway, I installed the attached to try to document auld lang syne.
On Sep 13, 2021, at 12:18 AM, Paul Eggert via tz <tz@iana.org> wrote:
Thanks for the background.
You participated in the tz mailing list thread: http://mm.icann.org/pipermail/tz/1998-May/010164.html in which he mentioned that back in 1998: http://mm.icann.org/pipermail/tz/1998-May/010159.html (things I learned from a Web search today; no, I didn't remember that discussion, either). (And, on one of the topics you addressed in your message:
What Epoch do systems that use leap seconds use?
In practice, such systems define 1972-01-01 00:00:00Z == (time_t) 63072000, i.e. it's as if there were no leap seconds before 1972.
Presumably systems that *don't* use leap seconds use the same definition.)
On 9/13/21 12:57 AM, Guy Harris wrote:
You participated in the tz mailing list thread:
Ha! I'd forgotten all about that too. I'd also forgotten about D.J.Berstein's statement that month <https://mm.icann.org/pipermail/tz/1998-May/010169.html>:
I don't see why anyone should waste time or energy on unused ideas such as negative leap seconds or rolling leap seconds. There's ample time to add these features if they are ever necessary. Arguments about "getting the code right" are silly: the code will have to be upgraded anyway in a few thousand years
Much of my recent tzdb activity has come from auditing tzcode for leap second issues, given that a negative leap second is a real possibility in the near future. I have in my pipeline a fix for what appears to be a genuine but very unlikely bug involving negative leap seconds, which I hope to publish later today.
While "3...2...1...leap" was mentioned on the mailing list in 1998, support for rolling leap seconds goes all the way back to the 1.1, 1988-01-25 version of the leapseconds file (included below). Folks looking for documentation of "3...2...1...leap" in New York might focus on 1987 or, before that, 1972 through 1979. (My guess 1987.) --ado # @(#)leapseconds 1.1 # Allowance for leapseconds added to each timezone file. # The correction (+ or -) is made at the given time, so lines # will typically look like: # Leap YEAR MON DAY 23:59:60 + R/S # or # Leap YEAR MON DAY 23:59:59 - R/S # If the leapsecond is Rolling (R) the given time is local time # If the leapsecond is Stationary (S) the given time is GMT # Leap YEAR MONTH DAY HH:MM:SS CORR R/S Leap 1972 Jun 30 23:59:60 + S Leap 1972 Dec 31 23:59:60 + S Leap 1973 Dec 31 23:59:60 + S Leap 1974 Dec 31 23:59:60 + S Leap 1975 Dec 31 23:59:60 + S Leap 1976 Dec 31 23:59:60 + S Leap 1977 Dec 31 23:59:60 + S Leap 1978 Dec 31 23:59:60 + S Leap 1979 Dec 31 23:59:60 + S Leap 1981 Jun 30 23:59:60 + S Leap 1982 Jun 30 23:59:60 + S Leap 1983 Jun 30 23:59:60 + S Leap 1985 Jun 30 23:59:60 + S Leap 1987 Dec 31 23:59:60 + S On Mon, Sep 13, 2021 at 3:57 AM Guy Harris <gharris@sonic.net> wrote:
On Sep 13, 2021, at 12:18 AM, Paul Eggert via tz <tz@iana.org> wrote:
Thanks for the background.
You participated in the tz mailing list thread:
http://mm.icann.org/pipermail/tz/1998-May/010164.html
in which he mentioned that back in 1998:
http://mm.icann.org/pipermail/tz/1998-May/010159.html
(things I learned from a Web search today; no, I didn't remember that discussion, either).
(And, on one of the topics you addressed in your message:
What Epoch do systems that use leap seconds use?
In practice, such systems define 1972-01-01 00:00:00Z == (time_t) 63072000, i.e. it's as if there were no leap seconds before 1972.
Presumably systems that *don't* use leap seconds use the same definition.)
On Mon, Sep 13, 2021 at 10:41 AM Arthur David Olson via tz <tz@iana.org> wrote:
support for rolling leap seconds goes all the way back to the 1.1, 1988-01-25 version of the leapseconds file
And that was simply because we (I) didn't know which of Stationary and Rolling was the "correct" treatment.
On 9/13/21 7:40 AM, Arthur David Olson wrote:
Folks looking for documentation of "3...2...1...leap" in New York might focus on 1987 or, before that, 1972 through 1979. (My guess 1987.)
I looked into this some more, and discovered that for 1988 there was a special Times Square production which extended the drop by one second and had a special light show during the leap second. The plans for this production are documented here: McFadden RD. '88 Countdown: 3, 2, 1, Leap Second, 0. New York Times. 1987-12-29. B1. https://www.nytimes.com/1987/12/29/nyregion/88-countdown-3-2-1-leap-second-0... McFadden wrote that officially the 1987-12-31 23:59:60 leap second was stationary, but that "unofficially" it was rolling through the US. However, when I reviewed YouTube videos of the Times Square event, it appeared that things didn't go off as smoothly as planned. For example: https://www.youtube.com/watch?v=kfySJJBFCRE This contains recordings of two broadcasts of the Times Square ball drop. In the first, the announcer says "3... 2... 1 leap and we're into '88!". However, the broadcast's digital clock inset (labeled "ABC TIME") has no leap second, and the announcer says "1 leap and" all within the same second to keep in sync with ABC TIME, so the leap second announcement was completely botched. That same YouTube video also contains a recording from another station, where there's also a digital clock inset with no leap second, and no mention of any leap second. So it appears that although the 1988 Times Squares organizers tried to observe a leap second at local midnight, many observers didn't get the point and so in some sense the observation did not work. I looked one other video of the 1988 New Year celebration, the Bill Graham / Grateful Dead celebration at Oakland Coliseum: https://www.youtube.com/watch?v=VZr13pQ9jZE and found no leap seconds. So here's what I suspect: * There was no longstanding tradition of observing a leap second at local midnight at Times Square. * 1988 was a one-off; the practice was not repeated. * McFadden's report that the leap second was rolling through the US was wishful thinking by the Times Square organizers. Further research and comments are welcome of course. Proposed further patch attached in the meantime.
participants (4)
-
Arthur David Olson -
Bradley White -
Guy Harris -
Paul Eggert