- tz - lists.iana.org

Leap year bugs
by Matt Johnson-Pint Jan. 24, 2020

Jan. 24, 2020

Hello Time People! Apologies in advance, as I know this is a bit off-topic being not about time zones, but I know that many of you are invested in date and time programming, and I'd appreciate some peer discussion. I've been invested in the last many months on preventative measures against leap year bugs, both in my day job at Microsoft and in the public space. Some of my recent posts: https://stackoverflow.com/questions/57530882/what-are-some-examples-of-leap… https://codeofmatt.com/on-the-life-cycle-of-a-leap-year-bug/ And from last leap year: https://codeofmatt.com/list-of-2016-leap-day-bugs/ https://azure.microsoft.com/en-us/blog/is-your-code-ready-for-the-leap-year/ Sometimes I feel like I'm overreacting, but then I remember the infamous 2012 Azure cloud leap day outage, and all the many other things across the industry that were impacted in 2016 (see my list above). My question for the community is this: Why are Y2K and Y2038 bugs such a hot topic when they are/were one-time events, but yet leap year bugs are rarely discussed even though they are recurring and can have critical impact? People seem to remember 20 years ago, but not 4 or 8 years back. Why? Are any of you working on leap year related issues? Have you checked your date math for leap year bugs? If not, why? Thanks, Matt

5 10

Re: [tz] Leap year bugs
by Hal Murray Jan. 24, 2020

Jan. 24, 2020

> [really hassles of being born on the leap day!] Many years ago, I got a "Congratulations for 10 years service" type certificate from a large corporation. It was dated Feb 29th. -- These are my opinions. I hate spam.

1 0

[PATCH] Cite Frumer on pre-1873 Japan timekeeping
by Paul Eggert Jan. 19, 2020

Jan. 19, 2020

* asia: Add a comment on timekeeping in Japan from the 7th to the 19th century. --- asia | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/asia b/asia index 590c05b..11a1726 100644 --- a/asia +++ b/asia @@ -1828,6 +1828,16 @@ Zone Asia/Jerusalem 2:20:54 - LMT 1880 # '9:00' and 'JST' is from Guy Harris. +# From Paul Eggert (2020-01-19): +# Starting in the 7th century, Japan generally followed an ancient Chinese +# timekeeping system that divided night and day into six hours each, +# with hour length depending on season. In 1873 the government +# started requiring the use of a Western style 24-hour clock. See: +# Yulia Frumer, "Making Time: Astronomical Time Measurement in Tokugawa Japan" +# <https://www.worldcat.org/oclc/1043907065>. As the tzdb code and +# data support only 24-hour clocks, its tables model timestamps before +# 1873 using Western-style local mean time. + # From Hideyuki Suzuki (1998-11-09): # 'Tokyo' usually stands for the former location of Tokyo Astronomical # Observatory: 139° 44' 40.90" E (9h 18m 58.727s), 35° 39' 16.0" N. -- 2.24.1

1 0

New leapseconds.awk doesn't work on macOS
by Chris Woodbury Jan. 17, 2020

Jan. 17, 2020

"leapseconds.awk" no longer has a CRLF problem per se. That is, just as long as we don't do something silly like printing strings with CRs in them (which we used to do but don't do now). At the time I reported the CRLF problem on 2019-07-27 at 05:47:10 UTC, leapseconds.awk was still using the comments as data to print the date of the zic "leap" directives it generates. (https://mm.icann.org/pipermail/tz/2019-July/028382.html) We don't do that anymore. The actual NTP timestamp datum is now being used to create the necessary date string thanks to Dr. Eggert's implementation of Dennis C. Ferguson's sstamp_to_ymdhMs() AWK function. (https://mm.icann.org/pipermail/tz/2019-September/028495.html) The two remaining string variables we use with CRs in them, the update and expiry NTP timestamps, are processed arithmetically before their values are printed. This eliminates the CRs as an issue with them. I still think it would be a good idea to use int() or strtonum() when they are read because the CRs *are* there. There are no leading zeroes to preserve (which was the primary objection I heard for not using int()). (https://blog.longnow.org/02013/12/31/long-now-years-five-digit-dates-and-10…) (Seven thousand nine hundred and eighty years from now...? This is farther in the future than the discovery of agriculture is in the past...) The sub() on $0 is unnecessary (and possibly bad practice). (I could argue on either side of the issue.) $ git diff leapseconds.awk diff --git a/leapseconds.awk b/leapseconds.awk index 924ade9..0e3eb1a 100755 --- a/leapseconds.awk +++ b/leapseconds.awk @@ -71,15 +71,13 @@ BEGIN { sstamp_init() } -# In case the input has CRLF form a la NIST. -{ sub(/\r$/, "") } - /^#[ \t]*[Uu]pdated through/ || /^#[ \t]*[Ff]ile expires on/ { last_lines = last_lines $0 "\n" } -/^#[$][ \t]/ { updated = $2 } -/^#[@][ \t]/ { expires = $2 } +# In case the input has CRLF form a la NIST. +/^#[$][ \t]/ { updated = int( $2 ) } +/^#[@][ \t]/ { expires = int( $2 ) } /^[ \t]*#/ { next }

2 1

[PROPOSED 1/3] Fix leap second bug after last explicit transition
by Paul Eggert Jan. 15, 2020

Jan. 15, 2020

The client code mishandled timestamps after the last explicit transition in a TZif file that had both leap seconds and daylight saving time transitions projected into the indefinite future. When interpreting the TZ string embedded at the end of the TZif file, the code neglected to adjust the corresponding DST transitions for leap seconds, which meant the DST transitions were calculated to occur too early. For example, with TZ set to '.../zoneinfo-leaps/America/Los_Angeles', zdump reported a DST transition on 2038-03-14 from 01:59:32.999... to 02:59:33 instead of the correct transition from 01:59:59.999... to 03:00:00. * NEWS: Mention this. * localtime.c (tzloadbody): Apply leap second corrections to transitions derived from the trailing TZ string in a TZif file. (leapcorr) [!STD_INSPIRED]: Define in this case too, since tzloadbody now uses it. --- NEWS | 8 ++++++++ localtime.c | 35 +++++++++++++++++++---------------- 2 files changed, 27 insertions(+), 16 deletions(-) diff --git a/NEWS b/NEWS index 961aa08..72e5c04 100644 --- a/NEWS +++ b/NEWS @@ -13,6 +13,14 @@ Unreleased, experimental changes Changes to code + localtime.c no longer mishandles timestamps after the last + transition in a TZif file with leap seconds and with daylight + saving time transitions projected into the indefinite future. + For example, with TZ='America/Los_Angeles' with leap seconds, + zdump formerly reported a DST transition on 2038-03-14 + from 01:59:32.999... to 02:59:33 instead of the correct transition + from 01:59:59.999... to 03:00:00. + The configuration macros HAVE_TZNAME and USG_COMPAT should now be set to 1 if the system library supports the feature, and 2 if not. As before, these macros are nonzero if tzcode should support the diff --git a/localtime.c b/localtime.c index d3f8fc7..6623eac 100644 --- a/localtime.c +++ b/localtime.c @@ -158,6 +158,7 @@ static struct tm *gmtsub(struct state const *, time_t const *, int_fast32_t, struct tm *); static bool increment_overflow(int *, int); static bool increment_overflow_time(time_t *, int_fast32_t); +static int_fast64_t leapcorr(struct state const *, time_t); static bool normalize_overflow32(int_fast32_t *, int *, int); static struct tm *timesub(time_t const *, int_fast32_t, struct state const *, struct tm *); @@ -641,11 +642,13 @@ tzloadbody(char const *name, struct state *sp, bool doextend, for (i = 0; i < ts->timecnt; i++) if (sp->timecnt == 0 - || sp->ats[sp->timecnt - 1] < ts->ats[i]) + || (sp->ats[sp->timecnt - 1] + < ts->ats[i] + leapcorr(sp, ts->ats[i]))) break; while (i < ts->timecnt && sp->timecnt < TZ_MAX_TIMES) { - sp->ats[sp->timecnt] = ts->ats[i]; + sp->ats[sp->timecnt] + = ts->ats[i] + leapcorr(sp, ts->ats[i]); sp->types[sp->timecnt] = (sp->typecnt + ts->types[i]); sp->timecnt++; @@ -2239,20 +2242,6 @@ timeoff(struct tm *tmp, long offset) #endif /* defined STD_INSPIRED */ -/* -** XXX--is the below the right way to conditionalize?? -*/ - -#ifdef STD_INSPIRED - -/* -** IEEE Std 1003.1 (POSIX) says that 536457599 -** shall correspond to "Wed Dec 31 23:59:59 UTC 1986", which -** is not the case if we are accounting for leap seconds. -** So, we provide the following conversion routines for use -** when exchanging timestamps with POSIX conforming systems. -*/ - static int_fast64_t leapcorr(struct state const *sp, time_t t) { @@ -2268,6 +2257,20 @@ leapcorr(struct state const *sp, time_t t) return 0; } +/* +** XXX--is the below the right way to conditionalize?? +*/ + +#ifdef STD_INSPIRED + +/* +** IEEE Std 1003.1 (POSIX) says that 536457599 +** shall correspond to "Wed Dec 31 23:59:59 UTC 1986", which +** is not the case if we are accounting for leap seconds. +** So, we provide the following conversion routines for use +** when exchanging timestamps with POSIX conforming systems. +*/ + NETBSD_INSPIRED_EXTERN time_t time2posix_z(struct state *sp, time_t t) { -- 2.24.1

3 7

Y2K quick-fix crick? Y2K20 bitten by 1970 + 50 year wrap
by Brian Inglis Jan. 15, 2020

Jan. 15, 2020

https://www.theregister.co.uk/2020/01/13/y2k_dvla/ https://gothamist.com/news/y2k20-parking-meter-software-glitch-causes-cityw… https://www.freightwaves.com/news/trimble-requests-extension-to-fmcsa-repai… -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised.

1 0

Re: [tz] Leap Second Support Interval Field Request - RFC8536
by Paul Eggert Jan. 15, 2020

Jan. 15, 2020

On 12/4/19 1:04 PM, Michael Veth wrote: > The NIST leapsecond bulletin includes an expiration time which serves to > indicate the maximum validity interval for use of UTC time. In order to > safely use UTC timestamps, the user needs to be aware of this maximum > validity time or they could be unknowingly introducing timing errors. > > I was not able to find this field in the TZif (Feb 19) ICD. Would it be > possible to add a field to the TZdb that would represent this expiration > time? The TZif file format does provide for truncated files (see Internet RFC 8536 section 5.1), and one can generate files truncated to the current UTC expiration time (2020-06-28 00:00:00 UTC) with a command like this: zic -r /@1593302427 -L leapseconds tzdata.zi However, it's awkward that one must count the number of seconds since 1970-01-01 00:00:00 UTC (including leap seconds) by hand to get the numeric timestamp (1593302427 in this case) to pass to zic. We could add support to zic to do this sort of thing in a more-natural way. A downside of the abovementioned approach is that it generates a TZif file that omits all DST and time zone transitions after the UTC expiration time. We could change the TZif format to represent UTC expiration time separately from the truncation time. One possibility would be to append a leap-second record with an "occur" value equal to the expiration time and a "corr" value equal to the previous record's "corr" value. Strictly speaking this would violate RFC 8536 section 3.2 "leap-second records" - though I doubt whether many clients would care - and so I suppose we'd need to increment the TZif format version number from 3 to 4. On the other hand, any files generated by this method would continue to be "incorrect" in that they'd continue to predict timestamps past the maximum leap second validity, so perhaps it wouldn't be worth going to all this work to generate "incorrect" files. I'll cc this to tz(a)iana.org and tzdist-bis(a)ietf.org to see whether anybody there cares to comment.

4 6

New leapseconds.awk doesn't work on macOS
by Deborah Goldsmith Jan. 11, 2020

Jan. 11, 2020

Hi, I just noticed that starting with 2019c, leapseconds.awk is producing a damaged leapseconds file on macOS, e.g.: > # All leap-seconds are Stationary (S) at the given UTC time. > # The correction (+ or -) is made at the given time, so in the unlikely > # event of a negative leap second, a line would look like this: > # Leap YEAR MON DAY 23:59:59 - S > # Typical lines look like this: > # Leap YEAR MON DAY 23:59:60 + S > > # POSIX timestamps for the data in this file: > #updated -2208988800 (1900-01-01 00:00:00 UTC) > #expires -2208988800 (1900-01-01 00:00:00 UTC) > It turns out that having a regex in RS is a gawk feature and is not supported in Darwin awk. Commenting out the definition of RS in leapseconds.awk fixed the problem. I don’t know how many customers of TZ will be using versions of awk that don’t support regexes in RS. I don’t know about FreeBSD, OpenBSD, etc. Thanks, Debbie

6 8

new NIST leap-seconds.list
by Chris Woodbury Jan. 10, 2020

Jan. 10, 2020

There is a new NIST leap-seconds.list (thanks to Dr. Judah Levine). diff --git a/leap-seconds.list b/leap-seconds.list index a1bc5a7..529dc4a 100644 --- a/leap-seconds.list +++ b/leap-seconds.list @@ -62,7 +62,7 @@ # Terry Quinn, "The BIPM and the Accurate Measurement # of Time," Proc. of the IEEE, Vol. 79, pp. 894-905, # July, 1991. <http://dx.doi.org/10.1109/5.84965> -# reprinted in: +# reprinted in: # Christine Hackman and Donald B Sullivan (eds.) # Time and Frequency Measurement # American Association of Physics Teachers (1996) @@ -204,10 +204,10 @@ # current -- the update time stamp, the data and the name of the file # will not change. # -# Updated through IERS Bulletin C58 -# File expires on: 28 June 2020 +# Updated through IERS Bulletin C59 +# File expires on: 28 December 2020 # -#@ 3802291200 +#@ 3818102400 # 2272060800 10 # 1 Jan 1972 2287785600 11 # 1 Jul 1972 @@ -252,4 +252,4 @@ # the hash line is also ignored in the # computation. # -#h f28827d2 f263b6c3 ec0f19eb a3e0dbf0 97f3fa30 +#h a1c168ae 27c79a7d 9dddcfc3 bcfe616b 2e2c44ea \ No newline at end of file

2 1

new NIST leap-seconds.list
by Chris Woodbury Jan. 10, 2020

Jan. 10, 2020

> On Fri, 10 Jan 2020 13:57:17 -0500, John Hawkinson <jhawk(a)alum.mit.edu> wrote: > Has this diff been hand-edited? There does not appear to be a difference at line 65 (middle of the first hunk)? > Or maybe something was lost though a copy/paste to email? A space was lost in cut/paste (mi culpa). In line 65, the extra space ("Reprinted in: ") was eliminated by Dr. Levine. $ sed -n -e 65p a/leap-seconds.list | od -c 0000000 # \t \t r e p r i n t e d i n : 0000020 \n 0000022 $ sed -n -e 65p b/leap-seconds.list | od -c 0000000 # \t \t r e p r i n t e d i n : 0000020 \n 0000021

1 0