- tz - lists.iana.org

Re: [tz] No leap second on 2021-12-31
by Kerry Shetline Sept. 14, 2021

Sept. 14, 2021

What’s interesting is that the Earth is undergoing an odd span of time during which it has been spinning a bit faster instead of slowing down. If this keeps up, not only will it be a while until we see another leap second, but in a few years we might experience the first negative leap second, where a second is dropped from the end of the last minute just before 00:00 UTC. > Per IERS, Bulletin C 62 (2021-07-05) > https://hpiers.obspm.fr/iers/bul/bulc/bulletinc.62 > > ?and forwarded below. > > A patch updating leap-seconds.list from NIST is attached, and is installed > in the development repository. > > -- > Tim Parenti

3 2

Further fix for Niue
by Tim Parenti Sept. 14, 2021

Sept. 14, 2021

While working on the recent changes to historical timestamps for Sierra Leone, the unique -11:20 offset for Niue caught my eye in contemporaneous editions of The Air Almanac which P Chan had sourced: specifically, that it was no longer there by the late 1960s. FInding a few more editions, I eventually found -11:20 listed for Niue as of Apr 1964 but -11 as of Aug 1964: Apr 1964: https://books.google.com/books?id=_1So677Y5vUC&pg=SL1-PA23 Aug 1964: https://books.google.com/books?id=MbJloqd-zyUC&pg=SL1-PA23 This points to a likely transition sometime around July 1964. 1978 did seem awfully late for such a unique offset. Proposed patch attached, and installed in the development repository. -- Tim Parenti On Wed, 24 Mar 2021 at 15:28, Paul Eggert via tz <tz(a)iana.org> wrote: > Thanks for the additional info about Cook and Niue. Proposed further > patch attached, and installed into the development repository. >

1 0

Historical fix for Tonga
by Tim Parenti Sept. 14, 2021

Sept. 14, 2021

First, a quick clerical patch: 0001, attached, fixes the placement of a comment which got shuffled around in the lead-up to publishing the changes for South Sudan in 2021a. Patch 0003 relates to Tonga, and comes from some of the links P Chan shared to 1957–1963 editions of The Air Almanac: https://mm.icann.org/pipermail/tz/2021-February/029866.html On Thu, 25 Feb 2021 at 03:43, P Chan <legco(a)outlook.com> wrote: > 1960 Nov (1962.1-4) > https://books.google.com/books?id=bVgtWM6kPZUC&pg=SL1-PA20 > 1961 Mar (1962.5-8) > https://books.google.com/books?id=W2nItAul4g0C&pg=SL1-PA20 When looking around at how this data was presented for other regions, I noticed on the preceding pages (listing "Places Fast on GMT", i.e., east of Greenwich) in some of the earlier editions provided that Tonga was listed at GMT+12:20. The peculiar offset stuck out, and I quickly noticed that some of the later editions of the same tables had it at GMT+13. A quick bisection puts the changeover, as far as The Air Almanac contemporaneously reckoned it, between November 1960 and March 1961. Previously, our data had Tonga transitioning to UT+13 in 1941 based on a quotation from a 1997 news article. Although this differs from what the Almanac suggests by some 20 years, the article does mention a change coincident with the New Year, and that Tāufaʻāhau Tupou IV was Crown Prince at the time. As his predecessor and mother, Queen Sālote Tupou III, reigned from 1918-04-05 to 1965-12-16, a possible transition of 1961-01-01 still jives with the gist of the article, even if the specific year was perhaps wrong or just misprinted. For what it's worth, our commentary already noted that Shanks & Pottenger had put the transition even later, at 1968-10-01. Although of course we don't know how they arrived at that date, given that they did, 1961 seems rather less out-of-place than it otherwise might. The attached patch 0003 makes this adjustment, while more fully documenting and comparing the conflicting sources. Thanks again to P Chan for pointing us to these resources. I wasn't expecting to get a "bonus" correction out of it, but one never knows quite what will catch the eye… -- Tim Parenti

3 3

[PATCH 1/8] * tzfile.5: Fix prefix/suffix typo (thanks to Ian Abbott).
by Paul Eggert Sept. 14, 2021

Sept. 14, 2021

--- tzfile.5 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tzfile.5 b/tzfile.5 index b4952d5..ec78689 100644 --- a/tzfile.5 +++ b/tzfile.5 @@ -134,7 +134,7 @@ bytes that represent time zone designations, which are null-terminated byte strings, each indexed by the .B tt_desigidx values mentioned above. -The byte strings can overlap if one is a prefix of the other. +The byte strings can overlap if one is a suffix of the other. The encoding of these strings is not specified. .IP * .B tzh_leapcnt -- 2.27.0

2 8

[PROPOSED] zic -r is incompatible with rolling leaps
by Paul Eggert Sept. 13, 2021

Sept. 13, 2021

* 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

4 7

Re: [tz] [PROPOSED] Fix ambiguous leapsecs by rolling up to a minute
by Paul Eggert Sept. 13, 2021

Sept. 13, 2021

On 9/13/21 2:45 AM, Robert Elz wrote: > do the changes in this proposal also correctly handle negative > leap seconds that are (for whatever bizarre reason) shoved into the middle > of a minute? Good question. I don't know of any problems in that area, though, as the proposed change does not affect negative leap seconds. The problem with 2021a and earlier is that localtime labels are ambiguous in a positive leap second inserted into the middle of a localtime minute; for example, if a leap second is inserted between seconds 11 and 12 the count is ... 9, 10, 11, 11, 12, 13,... which is problematic. With a negative leap second, the clock skips a second so there can be no ambiguity and there is no need for a fix. If the 11th second is skipped, for example, the localtime seconds is simply ... 9, 10, 12, 13,.... This has long been the case in the code, and the proposed change does not affect this.

1 0

[PROPOSED] Simplify zic's handling of -r
by Paul Eggert Sept. 13, 2021

Sept. 13, 2021

This is refactoring; it should not affect user-visible behavior. * zic.c (struct timerange): New member pretrans. (limitrange): New arg locut. Use it to set r.pretrans. All callers changed. (writezone): Initialize the new member, to avoid undefined behavior. Simplify by using the new member. --- zic.c | 70 +++++++++++++++++++++++++++++------------------------------ 1 file changed, 34 insertions(+), 36 deletions(-) diff --git a/zic.c b/zic.c index a4406cb..e2a7e13 100644 --- a/zic.c +++ b/zic.c @@ -1958,29 +1958,44 @@ struct timerange { int defaulttype; ptrdiff_t base, count; int leapbase, leapcount; - bool leapexpiry; + bool pretrans, leapexpiry; }; static struct timerange -limitrange(struct timerange r, zic_t lo, zic_t hi, +limitrange(struct timerange r, bool locut, zic_t lo, zic_t hi, zic_t const *ats, unsigned char const *types) { + /* Omit ordinary transitions < LO. */ while (0 < r.count && ats[r.base] < lo) { r.defaulttype = types[r.base]; r.count--; r.base++; } + + /* Omit as many leap seconds < LO as possible, such that the first + leap second in the truncated list is <= LO. */ while (1 < r.leapcount && trans[r.leapbase + 1] <= lo) { r.leapcount--; r.leapbase++; } + /* Omit ordinary and leap second transitions greater than HI + 1. */ if (hi < ZIC_MAX) { while (0 < r.count && hi + 1 < ats[r.base + r.count - 1]) r.count--; while (0 < r.leapcount && hi + 1 < trans[r.leapbase + r.leapcount - 1]) r.leapcount--; } + + /* Determine whether to keep the last too-low transition if no + transition is exactly at LO. The kept transition will be output + as a LO "transition"; see "Output a LO_TIME transition" below. + This is needed when the output is truncated at the start, and is + also useful when catering to buggy 32-bit clients that do not use + time type 0 for timestamps before the first transition. */ + r.pretrans = locut && ! (r.count && ats[r.base] == lo); + + /* Determine whether to append an expiration to the leap second table. */ r.leapexpiry = 0 <= leapexpires && leapexpires - 1 <= hi; return r; @@ -2092,9 +2107,11 @@ writezone(const char *const name, const char *const string, char version, rangeall.base = rangeall.leapbase = 0; rangeall.count = timecnt; rangeall.leapcount = leapcnt; - rangeall.leapexpiry = false; - range64 = limitrange(rangeall, lo_time, hi_time, ats, types); - range32 = limitrange(range64, INT32_MIN, INT32_MAX, ats, types); + rangeall.pretrans = rangeall.leapexpiry = false; + range64 = limitrange(rangeall, min_time < lo_time, + lo_time, hi_time, ats, types); + range32 = limitrange(range64, INT32_MIN < lo_time, + INT32_MIN, INT32_MAX, ats, types); /* TZif version 4 is needed if a no-op transition is appended to indicate the expiration of the leap second table, or if the first @@ -2129,7 +2146,7 @@ writezone(const char *const name, const char *const string, char version, register int thisleapi, thisleapcnt, thisleaplim; struct tzhead tzh; int currenttype, thisdefaulttype; - bool locut, hicut, thisleapexpiry; + bool hicut, pretrans, thisleapexpiry; zic_t lo; int old0; char omittype[TZ_MAX_TYPES]; @@ -2160,8 +2177,8 @@ writezone(const char *const name, const char *const string, char version, toomanytimes = thistimecnt >> 31 >> 1 != 0; thisleapi = range32.leapbase; thisleapcnt = range32.leapcount; + pretrans = range32.pretrans; thisleapexpiry = range32.leapexpiry; - locut = INT32_MIN < lo_time; hicut = hi_time < INT32_MAX; } else { thisdefaulttype = range64.defaulttype; @@ -2170,33 +2187,17 @@ writezone(const char *const name, const char *const string, char version, toomanytimes = thistimecnt >> 31 >> 31 >> 2 != 0; thisleapi = range64.leapbase; thisleapcnt = range64.leapcount; + pretrans = range64.pretrans; thisleapexpiry = range64.leapexpiry; - locut = min_time < lo_time; hicut = hi_time < max_time; } if (toomanytimes) error(_("too many transition times")); - /* Keep the last too-low transition if no transition is - exactly at LO. The kept transition will be output as - a LO "transition"; see "Output a LO_TIME transition" - below. This is needed when the output is truncated at - the start, and is also useful when catering to buggy - 32-bit clients that do not use time type 0 for - timestamps before the first transition. */ - if (0 < thistimei && ats[thistimei] != lo_time) { - thistimei--; - thistimecnt++; - locut = false; - } - thistimelim = thistimei + thistimecnt; - if (thistimecnt != 0) { - if (ats[thistimei] == lo_time) - locut = false; - if (hi_time < ZIC_MAX && ats[thistimelim - 1] == hi_time + 1) - hicut = false; - } + if (thistimecnt && hi_time < ZIC_MAX + && ats[thistimelim - 1] == hi_time + 1) + hicut = false; memset(omittype, true, typecnt); omittype[thisdefaulttype] = false; for (i = thistimei; i < thistimelim; i++) @@ -2291,11 +2292,9 @@ writezone(const char *const name, const char *const string, char version, indmap[desigidx[i]] = j; } if (pass == 1 && !want_bloat()) { - thisleapcnt = 0; - thisleapexpiry = false; - thistimecnt = - (locut + hicut); + pretrans = hicut = thisleapexpiry = false; + thistimecnt = thisleapcnt = 0; thistypecnt = thischarcnt = 1; - thistimelim = thistimei; } #define DO(field) fwrite(tzh.field, sizeof tzh.field, 1, fp) memset(&tzh, 0, sizeof tzh); @@ -2304,7 +2303,7 @@ writezone(const char *const name, const char *const string, char version, convert(utcnt, tzh.tzh_ttisutcnt); convert(stdcnt, tzh.tzh_ttisstdcnt); convert(thisleapcnt + thisleapexpiry, tzh.tzh_leapcnt); - convert(locut + thistimecnt + hicut, tzh.tzh_timecnt); + convert(pretrans + thistimecnt + hicut, tzh.tzh_timecnt); convert(thistypecnt, tzh.tzh_typecnt); convert(thischarcnt, tzh.tzh_charcnt); DO(tzh_magic); @@ -2331,16 +2330,15 @@ writezone(const char *const name, const char *const string, char version, for this pass. */ lo = pass == 1 && lo_time < INT32_MIN ? INT32_MIN : lo_time; - if (locut) + if (pretrans) puttzcodepass(lo, fp, pass); for (i = thistimei; i < thistimelim; ++i) { - zic_t at = ats[i] < lo ? lo : ats[i]; - puttzcodepass(at, fp, pass); + puttzcodepass(ats[i], fp, pass); } if (hicut) puttzcodepass(hi_time + 1, fp, pass); currenttype = 0; - if (locut) + if (pretrans) putc(currenttype, fp); for (i = thistimei; i < thistimelim; ++i) { currenttype = typemap[types[i]]; -- 2.31.1

1 0

[PATCH] Use https: for opengroup in zic.8
by Paul Eggert Sept. 12, 2021

Sept. 12, 2021

--- zic.8 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/zic.8 b/zic.8 index 800fb8b..b77841b 100644 --- a/zic.8 +++ b/zic.8 @@ -252,7 +252,7 @@ zero or more lines, each ending in a newline byte and containing at most 511 bytes, and without any NUL bytes. The input text's encoding is typically UTF-8 or ASCII; it should have a unibyte representation for the POSIX Portable Character Set (PPCS) -\*<http://pubs\*:.opengroup\*:.org/\*:onlinepubs/\*:9699919799/\*:basedefs/\*:…> +\*<https://pubs\*:.opengroup\*:.org/\*:onlinepubs/\*:9699919799/\*:basedefs/\*…> and the encoding's non-unibyte characters should consist entirely of non-PPCS bytes. Non-PPCS characters typically occur only in comments: although output file names and time zone abbreviations can contain -- 2.31.1

1 0

[PATCH] Port ‘check_time_t_alternatives’ to oddball hosts
by Paul Eggert Sept. 12, 2021

Sept. 12, 2021

* Makefile (TIME_T_ALTERNATIVES): Use int_least64_t instead of int64_t, as int64_t is not required by the C standard. Similarly for int32_t, uint32_t, uint64_t. --- Makefile | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Makefile b/Makefile index b00ac05..8a7436a 100644 --- a/Makefile +++ b/Makefile @@ -122,8 +122,8 @@ LIBDIR = $(TOPDIR)/$(USRDIR)/lib # Types to try, as an alternative to time_t. TIME_T_ALTERNATIVES = $(TIME_T_ALTERNATIVES_HEAD) $(TIME_T_ALTERNATIVES_TAIL) -TIME_T_ALTERNATIVES_HEAD = int64_t -TIME_T_ALTERNATIVES_TAIL = int32_t uint32_t uint64_t +TIME_T_ALTERNATIVES_HEAD = int_least64_t +TIME_T_ALTERNATIVES_TAIL = int_least32_t uint_least32_t uint_least64_t # What kind of TZif data files to generate. (TZif is the binary time # zone data format that zic generates; see Internet RFC 8536.) @@ -976,7 +976,7 @@ $(TIME_T_ALTERNATIVES): $(VERSION_DEPS) mkdir $@.dir ln $(VERSION_DEPS) $@.dir case $@ in \ - int32_t) range=-2147483648,2147483648;; \ + int*32_t) range=-2147483648,2147483648;; \ u*) range=0,4294967296;; \ *) range=-4294967296,4294967296;; \ esac && \ -- 2.31.1

1 0

request
by Cool Gab19 Sept. 12, 2021

Sept. 12, 2021

I request Etc/GMT-15 or +15 be included in your database https://github.com/gabtimezone15/tz/blob/d0970deeac9041a1e8a585782ccec3a1ef…

2 2