January 2020 - tz - lists.iana.org

Italy April 1944 discrepancy between comment and data
by Alois Treindl Oct. 5, 2021

Oct. 5, 2021

For Italy in 1944 zone Europe/Rome there is a discrepancy between the comment and the data. comment: # From Paul Eggert (2016-10-27): # Go with INRiM for DST rules, except as corrected by Inglis for 1944 # for the Kingdom of Italy. This is consistent with Renzo Baldini. # Model Rome's occupation by using C-Eur rules from 1943-09-10 # to 1944-06-04; although Rome was an open city during this period, it # was effectively controlled by Germany. Data for Italy is Rule Italy 1944 only - Apr 2 2:00s 1:00 S Data for C-Eur is: Rule C-Eur 1944 1945 - Apr Mon>=1 2:00s 1:00 S where Mon>=1 in 1944 is April 3. So Rome is NOT following C-Eur. I think the rule for Itay is right, only the comment is misleading.

4 9

'Australia/Canberra' time zone?
by John Pye April 24, 2020

April 24, 2020

Hi there I have been a bit surprised that the TZDATA database lacks a listing for "Australia/Canberra", population 350,000. What is the basis for deciding which cities are included or excluded from the database? Does being the national capital, and the major city in its own state/territory warrant inclusion, or is there another criterion? Here is what I believe to be an official source about the Canberra timezone (at least for the present day): https://www.australia.gov.au/about-australia/facts-and-figures/time-zones-a… Cheers JP

8 19

tzdb data for North and Central America
by Jeffery Nichols Jan. 24, 2020

Jan. 24, 2020

Hello. You might want to note that the America/Halifax timezone also applies to Îles-de-la-Madeleine and the Listuguj reserve in Quebec. Officially, this came into effect on January 1, 2007 (*Legal Time Act*, CQLR c T-5.1), but the legislative debates surrounding that bill say that it is "accommodating the customs and practices" of those regions, which suggests that they have always been in-line with Halifax. Also, you call America/Whitehorse "south Yukon" and America/Dawson "north Yukon", but the divide is actually between east and west, at the 138th meridian. -- *Jeffery Nichols*, JD, MPA, MA

8 11

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. 14, 2020

Jan. 14, 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