- tz - lists.iana.org

[PROPOSED] Improve leap second table truncation doc
by Paul Eggert Sept. 16, 2021

Sept. 16, 2021

* NEWS: Mention possible successor to RFC 8536, and relaxation on TZif reader’s restriction on gaps between leaps. * tzfile.5: Improve wording on leap second expiration. Specify correction before truncated leap second table more accurately, given how localtime.c behaves; for example, the first leap second is considered to be positive if and only if its correction is positive. Say what to do after leap second table expires. Add TZ="XXX3EDT4,0/0,J365/23" example. Say that positive leap seconds not at end of localtime minute have not been a practical problem yet. * tzfile.5, zic.8: Use \- (current font minus) instead of \(mi (math font minus). --- NEWS | 6 ++++- tzfile.5 | 77 ++++++++++++++++++++++++++++++++++++++------------------ zic.8 | 2 +- 3 files changed, 58 insertions(+), 27 deletions(-) diff --git a/NEWS b/NEWS index cc69995..00dea3c 100644 --- a/NEWS +++ b/NEWS @@ -86,7 +86,8 @@ Unreleased, experimental changes clients (including tzdb 2017c through 2021a) reject it, so "Expires" directives are currently disabled by default. To enable them, set the EXPIRES_LINE Makefile variable. If a TZif file uses - this new feature it is marked with a new TZif version number 4. + this new feature it is marked with a new TZif version number 4, + a format intended to be documented in a successor to RFC 8536. zic -L LEAPFILE -r @LO no longer generates an invalid TZif file that omits leap second information for the range LO..B when LO @@ -98,6 +99,9 @@ Unreleased, experimental changes correction other than -1 or +1, and to contain adjacent transitions with equal corrections. This supports TZif version 4. + The TZif reader now lets leap seconds occur less than 28 days + apart. This supports possible future TZif extensions. + Fix bug that caused 'localtime' etc. to crash when TZ was set to a all-year DST string like "EST5EDT4,0/0,J365/25" that does not conform to POSIX but does conform to Internet RFC 8536. diff --git a/tzfile.5 b/tzfile.5 index bab6390..b1932bd 100644 --- a/tzfile.5 +++ b/tzfile.5 @@ -142,16 +142,26 @@ pairs of four-byte values, written in network byte order; the first value of each pair gives the nonnegative time (as returned by .BR time (2)) -at which a leap second occurs; +at which a leap second occurs or at which the leap second table expires; the second is a signed integer specifying the correction, which is the .I total number of leap seconds to be applied during the time period starting at the given time. -The pairs of values are sorted in ascending order by time. -Each transition is for one leap second, either positive or negative; -transitions always separated by at least 28 days minus 1 second. -The first entry's correction is +1 (or \(mi1, for a hypothetical leap -second table where the first leap second was negative). +The pairs of values are sorted in strictly ascending order by time. +Each pair denotes one leap second, either positive or negative, +except that if the last pair has the same correction as the previous one, +the last pair denotes the leap second table's expiration time. +Each leap second is at the end of a UTC calendar month. +The first leap second is positive if and only if its correction is positive, +and the correction for each leap second after the first differs +from the previous leap second by either 1 for a positive leap second, +or \-1 for a negative leap second. +If the leap second table is empty, the leap-second correction is zero +for all timestamps; +otherwise, for timestamps before the first correction time, +the leap-second correction is zero if the first pair's correction is 1 or \-1, +and is unspecified otherwise (which can happen only in files +truncated at the start). .IP * .B tzh_ttisstdcnt standard/wall indicators, each stored as a one-byte boolean; @@ -201,7 +211,7 @@ POSIX-TZ-environment-variable-style string for use in handling instants after the last transition time stored in the file or for all instants if the file has no transitions. The POSIX-style TZ string is empty (i.e., nothing between the newlines) -if there is no POSIX representation for such instants. +if there is no POSIX-style representation for such instants. If nonempty, the POSIX-style TZ string must agree with the local time type after the last transition time if present in the eight-byte data; for example, given the string @@ -225,8 +235,8 @@ January 1 at 00:00 and ends December 31 at 24:00 plus the difference between daylight saving and standard time. .SS Version 4 format For version-4-format TZif files, -the first leap second transition can have a correction that is neither -+1 nor \(mi1, to support TZif files with reduced timestamp range. +the first leap second record can have a correction that is neither ++1 nor \-1, to represent truncation of the TZif file at the start. Also, if two or more leap second transitions are present and the last entry's correction equals the previous one, the last entry denotes the expiration of the leap second table instead of a leap second; @@ -237,32 +247,37 @@ the added leap seconds will change how post-expiration timestamps are treated. Future changes to the format may append more data. .PP Version 1 files are considered a legacy format and -should be avoided, as they do not support transition +should not be generated, as they do not support transition times after the year 2038. -Readers that only understand Version 1 must ignore +Readers that understand only Version 1 must ignore any data that extends beyond the calculated end of the version 1 data block. .PP Other than version 1, writers should generate the lowest version number needed by a file's data. For example, a writer should generate a version 3 file -if the file does not contain a truncated leap second table +if its leap second table neither expires nor is truncated at the start and so does not use version 4 features, but TZ string extensions are necessary to accurately model transition times so the file does need version 3 features. .PP The sequence of time changes defined by the version 1 -header and data block should be a contiguous subsequence +header and data block should be a contiguous sub-sequence of the time changes defined by the version 2+ header and data block, and by the footer. This guideline helps obsolescent version 1 readers agree with current readers about timestamps within the -contiguous subsequence. It also lets writers not +contiguous sub-sequence. It also lets writers not supporting obsolescent readers use a .B tzh_timecnt of zero in the version 1 data block to save space. .PP +When a TZif file contains a leap second table expiration +time, TZif readers should either refuse to process +post-expiration timestamps, or process them as if the expiration +time did not exist (possibly with an error indication). +.PP Time zone designations should consist of at least three (3) and no more than six (6) ASCII characters from the set of alphanumerics, @@ -272,7 +287,7 @@ and This is for compatibility with POSIX requirements for time zone abbreviations. .PP -When reading a version 2+ file, readers +When reading a version 2 or higher file, readers should ignore the version 1 header and data block except for the purpose of skipping over them. .PP @@ -306,7 +321,7 @@ design goal has been that a reader can successfully use a TZif file even if the file is of a later TZif version than what the reader was designed for. When complete compatibility was not achieved, an attempt was -made to limit glitches to rarely-used timestamps, and to allow +made to limit glitches to rarely used timestamps and allow simple partial workarounds in writers designed to generate new-version data useful even for older-version readers. This section attempts to document these compatibility issues and @@ -323,24 +338,33 @@ version 2+ data even if the reader's native timestamps have only 32 bits. .IP * Some readers designed for version 2 might mishandle -timestamps after a version 3 file's last transition, because +timestamps after a version 3 or higher file's last transition, because they cannot parse extensions to POSIX in the TZ-like string. As a partial workaround, a writer can output more transitions than necessary, so that only far-future timestamps are mishandled by version 2 readers. .IP * Some readers designed for version 2 do not support -permanent daylight saving time, e.g., a TZ string +permanent daylight saving time with transitions after 24:00 +\(en e.g., a TZ string .q "EST5EDT,0/0,J365/25" -denoting permanent Eastern Daylight Time (\-04). -As a partial workaround, a writer can substitute standard time -for the next time zone east, e.g., +denoting permanent Eastern Daylight Time +(\-04). +As a workaround, a writer can substitute standard time +for two time zones east, e.g., +.q "XXX3EDT4,0/0,J365/23" +for a time zone with a never-used standard time (XXX, \-03) +and negative daylight saving time (EDT, \-04) all year. +Alternatively, +as a partial workaround a writer can substitute standard time +for the next time zone east \(en e.g., .q "AST4" -for permanent Atlantic Standard Time (\-04). +for permanent +Atlantic Standard Time (\-04). .IP * -Some readers designed for earlier versions reject version 4 files, -because they require complete leap second tables that do not record -expiration dates. +Some readers designed for version 2 or 3, and that require strict +conformance to RFC 8536, reject version 4 files whose leap second +tables are truncated at the start or that end in expiration times. .IP * Some readers ignore the footer, and instead predict future timestamps from the time type of the last transition. @@ -413,6 +437,9 @@ a positive leap second 78796801 (1972-06-30 23:59:60 UTC), they map both 78796800 and 78796801 to 01:23:45 local time the next day instead of mapping the latter to 01:23:46, and they map 78796815 to 01:23:59 instead of to 01:23:60. +This has not yet been a practical problem, since no civil authority +has observed such UTC offsets since leap seconds were +introduced in 1972. .PP Some interoperability problems are reader bugs that are listed here mostly as warnings to developers of readers. diff --git a/zic.8 b/zic.8 index 3149440..ea7bab9 100644 --- a/zic.8 +++ b/zic.8 @@ -550,7 +550,7 @@ using the shortest form that does not lose information, where .IR mm , and .I ss -are the hours, minutes, and seconds east (+) or west (\(mi) of UT. +are the hours, minutes, and seconds east (+) or west (\-) of UT. Alternatively, a slash (/) separates standard and daylight abbreviations. -- 2.30.2

1 0

[CfP][CalendarFest] Call for lightning talk proposals for CalendarFest 2021 - current topics in electronic calendaring
by Hans-Joerg Happel Sept. 15, 2021

Sept. 15, 2021

Hi, my apologies for being slightly off topic, but I guess this might be interesting to see some of you / related to some topics discussed on this list. Please feel also free to forward this to anybody you might have in mind, who is dealing with novel calendaring solutions and ideas and might be interested in community discussion. Thanks and best, Hans-Joerg ----- CalendarFest is a novel (virtual) event, which wants to let users and developers of (electronic) calendar applications, servers, and related groupware systems, share experiences and discuss novel ideas. CalendarFest will take place *18th of October*, 02:30h PM UTC virtually via Zoom, and is held in conjunction with the CalConnect virtual conference <https://www.calconnect.org/events/calconnect-virtual-conference-autumn-2021>. Lightning talks People who wish to discuss or present certain topics are invited to submit a *proposal for lightning talks*. Lightning Talk presentations will be a maximum of 15-20 minutes each. Presenters may use slides, but these must be submitted to the Lightning Talks chair a few days before the presentation. Proposals Lightning Talk proposals must be submitted in PDF format. The proposal is limited to 1 page, 500 words max. The full proposal contains a title, an abstract (maximum 250 words) and a description where you should explain your talk in more detail. It will be helpful for reviewers to know why you are excited about the topic, and why you think others will be interested too. Outline how you plan to present your topic. The proposal also may contain a link to a website with more information. Possible Topics * Enterprise calendaring * Public calendaring * Calendaring and Semantic Web/Linked Data * Calendar Interoperability and Migration * Calendaring Security and Privacy by Design * Personal information management (PIM) and groupware * AI in calendaring * Calendaring and scheduling in IoT * Mobile calendaring * Calendar visualization, user experience and usability * Novel applications of calendars * Calendaring standards (vCard, iCal, CalDAV, CardDAV, JMAP) * Date/Time representations and Time zones * Business models for calendaring and groupware Program committee Submissions will be reviewed by the following members of the CalConnect TC-CLIENT technical committee: * Mike Douglass * Hans-Jörg Happel * Alex Nimmervoll Timeline * Send your lightning talk proposal to *calendarfest(a)calconnect.org <mailto:calendarfest@calconnect.org>* until *October, 4th* * You will receive a notification of acceptance or reject by October, 11th * CalendarFest will take place on October, 18th Participation Participation at CalendarFest will be free for presenters of accepted talks. Other participants need to register <https://www.calconnect.org/news/2021/09/02/registration-open-october-2021-c…> for a small organizational fee, which also allows for participation at the “colocated” CalConnect Virtual Conference. About CalConnect (www.calconnect.org <http://www.calconnect.org>) is a non-profit partnership between vendors and users of collaboration systems and tools, in particular calendaring and scheduling. CalConnect members convene regularly to discuss and develop standards for electronic calendaring and related topics. The goal of CalendarFest, which is held in conjunction with the CalConnect Virtual Conference, is to provide an interdisciplinary discussion space for current topics in electronic calendaring from different perspectives. *CalendarFest website: https://public.calconnect.org/CalendarFest/*

1 0

[PROPOSED] Don't mistruncate TZif files at leap seconds
by Paul Eggert Sept. 14, 2021

Sept. 14, 2021

Without this fix, zic mishandles the command ‘zic -L leapseconds -r @1706745601 etcetera’ when ‘leapseconds’ is generated from the test data file mentioned in: https://mm.icann.org/pipermail/tz/2021-September/030385.html The resulting, incorrect TZif file causes ‘TZ=Etc/GMT date -r 1706745601’ to output "Thu Feb 1 00:00:01 GMT 2024" instead of the correct "Thu Feb 1 00:00:00 GMT 2024", because localtime misinterprets the leap second entry at 1706745601 to be a positive instead of a negative leap second. * NEWS: Mention the fix. * zic.c (limitrange): When omitting leading leap seconds, do not output a leap second table that starts with a positive leap second with a nonpositive correction (or with a negative leap second with a positive correction) as that will confuse TZif readers into thinking the positive leap second is negative or vice versa. Instead, keep otherwise-unnecessary leading leap seconds to avoid the confusion. --- NEWS | 6 ++++++ zic.c | 14 ++++++++++++-- 2 files changed, 18 insertions(+), 2 deletions(-) diff --git a/NEWS b/NEWS index 62a7ba2..9983f11 100644 --- a/NEWS +++ b/NEWS @@ -137,6 +137,12 @@ Unreleased, experimental changes last time transition disagreed with the TZ string, contrary to Internet RFC 8563 section 3.3. + Fix a bug with 'zic -r @X' when X is a negative leap second that + has a nonnegative correction. Without the fix, the output file + was truncated so that X appeared to be a positive leap second. + Fix a similar, even-less-likely bug when truncating at a positive + leap second that has a nonpositive correction. + zic -r now reports an error if given rolling leap seconds, as this usage has never generally worked and is evidently unused. diff --git a/zic.c b/zic.c index b06ef66..c6feb8b 100644 --- a/zic.c +++ b/zic.c @@ -1972,12 +1972,22 @@ limitrange(struct timerange r, bool locut, zic_t lo, zic_t hi, r.base++; } - /* Omit as many leap seconds < LO as possible, such that the first - leap second in the truncated list is <= LO. */ + /* Omit as many initial leap seconds as possible, such that the + first leap second in the truncated list is <= LO, and is a + positive leap second if and only if it has a positive correction. + This supports common TZif readers that assume that the first leap + second is positive if and only if its correction is positive. */ while (1 < r.leapcount && trans[r.leapbase + 1] <= lo) { r.leapcount--; r.leapbase++; } + while (0 < r.leapbase + && ((corr[r.leapbase - 1] < corr[r.leapbase]) + != (0 < corr[r.leapbase]))) { + r.leapcount++; + r.leapbase--; + } + /* Omit ordinary and leap second transitions greater than HI + 1. */ if (hi < ZIC_MAX) { -- 2.30.2

1 0

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

[PROPOSED] Omit some casts
by Paul Eggert Sept. 11, 2021

Sept. 11, 2021

* localtime.c (getsecs, localsub, timesub): * strftime.c (_fmt): * zdump.c (dumptime): * zic.c (rcomp, atcomp): Rely on automatic conversions instead of casts, which are more error-prone. --- localtime.c | 13 +++++++------ strftime.c | 12 +++++++----- zdump.c | 17 ++++++----------- zic.c | 11 +++++------ 4 files changed, 25 insertions(+), 28 deletions(-) diff --git a/localtime.c b/localtime.c index cc972ef..88fd35d 100644 --- a/localtime.c +++ b/localtime.c @@ -862,6 +862,7 @@ static const char * getsecs(register const char *strp, int_fast32_t *const secsp) { int num; + int_fast32_t secsperhour = SECSPERHOUR; /* ** 'HOURSPERDAY * DAYSPERWEEK - 1' allows quasi-Posix rules like @@ -872,7 +873,7 @@ getsecs(register const char *strp, int_fast32_t *const secsp) strp = getnum(strp, &num, 0, HOURSPERDAY * DAYSPERWEEK - 1); if (strp == NULL) return NULL; - *secsp = num * (int_fast32_t) SECSPERHOUR; + *secsp = num * secsperhour; if (*strp == ':') { ++strp; strp = getnum(strp, &num, 0, MINSPERHOUR - 1); @@ -1544,7 +1545,7 @@ localsub(struct state const *sp, time_t const *timep, int_fast32_t setname, hi = mid; else lo = mid + 1; } - i = (int) sp->types[lo - 1]; + i = sp->types[lo - 1]; } ttisp = &sp->ttis[i]; /* @@ -1757,18 +1758,18 @@ timesub(const time_t *timep, int_fast32_t offset, tmp->tm_wday %= DAYSPERWEEK; if (tmp->tm_wday < 0) tmp->tm_wday += DAYSPERWEEK; - tmp->tm_hour = (int) (rem / SECSPERHOUR); + tmp->tm_hour = rem / SECSPERHOUR; rem %= SECSPERHOUR; - tmp->tm_min = (int) (rem / SECSPERMIN); + tmp->tm_min = rem / SECSPERMIN; /* ** A positive leap second requires a special ** representation. This uses "... ??:59:60" et seq. */ - tmp->tm_sec = (int) (rem % SECSPERMIN) + hit; + tmp->tm_sec = rem % SECSPERMIN + hit; ip = mon_lengths[isleap(y)]; for (tmp->tm_mon = 0; idays >= ip[tmp->tm_mon]; ++(tmp->tm_mon)) idays -= ip[tmp->tm_mon]; - tmp->tm_mday = (int) (idays + 1); + tmp->tm_mday = idays + 1; tmp->tm_isdst = 0; #ifdef TM_GMTOFF tmp->TM_GMTOFF = offset; diff --git a/strftime.c b/strftime.c index 4f871cd..5273155 100644 --- a/strftime.c +++ b/strftime.c @@ -335,11 +335,13 @@ label: && tm.tm_sec == tm_1.tm_sec)) return NULL; } - if (TYPE_SIGNED(time_t)) - sprintf(buf, "%"PRIdMAX, - (intmax_t) mkt); - else sprintf(buf, "%"PRIuMAX, - (uintmax_t) mkt); + if (TYPE_SIGNED(time_t)) { + intmax_t n = mkt; + sprintf(buf, "%"PRIdMAX, n); + } else { + uintmax_t n = mkt; + sprintf(buf, "%"PRIuMAX, n); + } pt = _add(buf, pt, ptlim); } continue; diff --git a/zdump.c b/zdump.c index 9d22b26..e198b04 100644 --- a/zdump.c +++ b/zdump.c @@ -1155,8 +1155,6 @@ dumptime(register const struct tm *timeptr) "Jan", "Feb", "Mar", "Apr", "May", "Jun", "Jul", "Aug", "Sep", "Oct", "Nov", "Dec" }; - register const char * wn; - register const char * mn; register int lead; register int trail; @@ -1169,16 +1167,13 @@ dumptime(register const struct tm *timeptr) ** values in tm_wday or tm_mon, but since this code might be compiled ** with other (perhaps experimental) versions, paranoia is in order. */ - if (timeptr->tm_wday < 0 || timeptr->tm_wday >= - (int) (sizeof wday_name / sizeof wday_name[0])) - wn = "???"; - else wn = wday_name[timeptr->tm_wday]; - if (timeptr->tm_mon < 0 || timeptr->tm_mon >= - (int) (sizeof mon_name / sizeof mon_name[0])) - mn = "???"; - else mn = mon_name[timeptr->tm_mon]; printf("%s %s%3d %.2d:%.2d:%.2d ", - wn, mn, + ((0 <= timeptr->tm_wday + && timeptr->tm_wday < sizeof wday_name / sizeof wday_name[0]) + ? wday_name[timeptr->tm_wday] : "???"), + ((0 <= timeptr->tm_mon + && timeptr->tm_mon < sizeof mon_name / sizeof mon_name[0]) + ? mon_name[timeptr->tm_mon] : "???"), timeptr->tm_mday, timeptr->tm_hour, timeptr->tm_min, timeptr->tm_sec); #define DIVISOR 10 diff --git a/zic.c b/zic.c index 4c55f1c..a4406cb 100644 --- a/zic.c +++ b/zic.c @@ -1225,8 +1225,8 @@ itssymlink(char const *name) static int rcomp(const void *cp1, const void *cp2) { - return strcmp(((const struct rule *) cp1)->r_name, - ((const struct rule *) cp2)->r_name); + struct rule const *r1 = cp1, *r2 = cp2; + return strcmp(r1->r_name, r2->r_name); } static void @@ -1949,10 +1949,9 @@ puttzcodepass(zic_t val, FILE *fp, int pass) static int atcomp(const void *avp, const void *bvp) { - const zic_t a = ((const struct attype *) avp)->at; - const zic_t b = ((const struct attype *) bvp)->at; - - return (a < b) ? -1 : (a > b); + struct attype const *ap = avp, *bp = bvp; + zic_t a = ap->at, b = bp->at; + return a < b ? -1 : a > b; } struct timerange { -- 2.31.1

1 0

[PATCH] Fix tzfile.h comment
by Paul Eggert Sept. 11, 2021

Sept. 11, 2021

* tzfile.h (struct tzhead): Update comment for version 4. --- tzfile.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tzfile.h b/tzfile.h index ee91104..9c3ea4e 100644 --- a/tzfile.h +++ b/tzfile.h @@ -44,7 +44,7 @@ struct tzhead { char tzh_magic[4]; /* TZ_MAGIC */ - char tzh_version[1]; /* '\0' or '2' or '3' as of 2013 */ + char tzh_version[1]; /* '\0' or '2'-'4' as of 2021 */ char tzh_reserved[15]; /* reserved; must be zero */ char tzh_ttisutcnt[4]; /* coded number of trans. time flags */ char tzh_ttisstdcnt[4]; /* coded number of trans. time flags */ -- 2.31.1

1 0

[PATCH] Change is_digit from macro to function
by Paul Eggert Sept. 11, 2021

Sept. 11, 2021

This is cleaner and should be no slower with modern optimizers. * localtime.c, zdump.c (is_digit): New static function, replacing the old macro. * private.h (is_digit): Remove this macro. --- localtime.c | 7 +++++++ private.h | 3 --- zdump.c | 8 ++++++-- 3 files changed, 13 insertions(+), 5 deletions(-) diff --git a/localtime.c b/localtime.c index 5f362d4..cc972ef 100644 --- a/localtime.c +++ b/localtime.c @@ -778,6 +778,13 @@ static const int year_lengths[2] = { DAYSPERNYEAR, DAYSPERLYEAR }; +/* Is C an ASCII digit? */ +static bool +is_digit(char c) +{ + return '0' <= c && c <= '9'; +} + /* ** Given a pointer into a timezone string, scan until a character that is not ** a valid character in a time zone abbreviation is found. diff --git a/private.h b/private.h index 98ead55..4c03324 100644 --- a/private.h +++ b/private.h @@ -225,9 +225,6 @@ #define R_OK 4 #endif /* !defined R_OK */ -/* Unlike <ctype.h>'s isdigit, this also works if c < 0 | c > UCHAR_MAX. */ -#define is_digit(c) ((unsigned)(c) - '0' <= 9) - /* ** Define HAVE_STDINT_H's default value here, rather than at the ** start, since __GLIBC__ and INTMAX_MAX's values depend on diff --git a/zdump.c b/zdump.c index 3c71894..9d22b26 100644 --- a/zdump.c +++ b/zdump.c @@ -99,8 +99,12 @@ static void showtrans(char const *, struct tm const *, time_t, char const *, static const char *tformat(void); static time_t yeartot(intmax_t) ATTRIBUTE_PURE; -/* Unlike <ctype.h>'s isdigit, this also works if c < 0 | c > UCHAR_MAX. */ -#define is_digit(c) ((unsigned)(c) - '0' <= 9) +/* Is C an ASCII digit? */ +static bool +is_digit(char c) +{ + return '0' <= c && c <= '9'; +} /* Is A an alphabetic character in the C locale? */ static bool -- 2.31.1

1 0

[PROPOSED] Relax leap-second pickiness
by Paul Eggert Sept. 10, 2021

Sept. 10, 2021

* localtime.c (tzloadbody): Relax requirements on the leap second table in a TZif file, to accommodate truncation at the start that is less than 28 days before a leap second, or (unlikely, though theoretically possible) expiration less than 28 days after the last leap second. --- localtime.c | 23 ++++++++++------------- 1 file changed, 10 insertions(+), 13 deletions(-) diff --git a/localtime.c b/localtime.c index e4f1a87..5f362d4 100644 --- a/localtime.c +++ b/localtime.c @@ -436,7 +436,7 @@ tzloadbody(char const *name, struct state *sp, bool doextend, for (stored = 4; stored <= 8; stored *= 2) { int_fast32_t ttisstdcnt = detzcode(up->tzhead.tzh_ttisstdcnt); int_fast32_t ttisutcnt = detzcode(up->tzhead.tzh_ttisutcnt); - int_fast64_t prevtr = 0; + int_fast64_t prevtr = -1; int_fast32_t prevcorr; int_fast32_t leapcnt = detzcode(up->tzhead.tzh_leapcnt); int_fast32_t timecnt = detzcode(up->tzhead.tzh_timecnt); @@ -526,24 +526,21 @@ tzloadbody(char const *name, struct state *sp, bool doextend, int_fast64_t tr = stored == 4 ? detzcode(p) : detzcode64(p); int_fast32_t corr = detzcode(p + stored); p += stored + 4; - /* Leap seconds cannot occur before the Epoch. */ - if (tr < 0) + /* Leap seconds cannot occur before the Epoch, + or out of order. */ + if (tr <= prevtr) return EINVAL; if (tr <= TIME_T_MAX) { - /* Leap seconds cannot occur more than once per UTC month, - and UTC months are at least 28 days long (minus 1 - second for a negative leap second). Each leap second's + /* To avoid other botches in this code, each leap second's correction must differ from the previous one's by 1 second or less, except that the first correction can be any value; these requirements are more generous than RFC 8536, to allow future RFC extensions. */ - if (tr - prevtr < 28 * SECSPERDAY - 1 - || ((timecnt == 0 || sp->ats[0] < tr) - && ! (i == 0 - || (prevcorr < corr - ? corr == prevcorr + 1 - : (corr == prevcorr - || corr == prevcorr - 1))))) + if (! (i == 0 + || (prevcorr < corr + ? corr == prevcorr + 1 + : (corr == prevcorr + || corr == prevcorr - 1)))) return EINVAL; sp->lsis[leapcnt].ls_trans = prevtr = tr; sp->lsis[leapcnt].ls_corr = prevcorr = corr; -- 2.31.1

1 0

Format for Asia/Bangkok
by Danilo Spinella Sept. 10, 2021

Sept. 10, 2021

Hi there! I have noticed that the format for the zone Asia/Bangkok is shown as "+07" instead of Indochina Time (ICT), Western Indonesian Time (WIB) or Thailand Standard Time (THA). Is this because none of the above is standard? Best Regards, Danilo Spinella

2 1

[PATCH] White space fixes
by Paul Eggert Sept. 10, 2021

Sept. 10, 2021

--- localtime.c | 2 +- zdump.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/localtime.c b/localtime.c index a70b67a..e4f1a87 100644 --- a/localtime.c +++ b/localtime.c @@ -2379,7 +2379,7 @@ time(time_t *p) if (r != (time_t) -1) { int_fast32_t offset = EPOCH_LOCAL ? (daylight ? timezone : altzone) : 0; if (increment_overflow32(&offset, -EPOCH_OFFSET) - || increment_overflow_time (&r, offset)) { + || increment_overflow_time(&r, offset)) { errno = EOVERFLOW; r = -1; } diff --git a/zdump.c b/zdump.c index f2ff442..3c71894 100644 --- a/zdump.c +++ b/zdump.c @@ -73,7 +73,7 @@ extern int optind; #endif /* The minimum and maximum finite time values. */ -enum { atime_shift = CHAR_BIT * sizeof (time_t) - 2 }; +enum { atime_shift = CHAR_BIT * sizeof(time_t) - 2 }; static time_t const absolute_min_time = ((time_t) -1 < 0 ? (- ((time_t) ~ (time_t) 0 < 0) -- 2.30.2

1 0

Re: [tz] ICANN News Alert - ICANN to Manage Time Zone Database
by Parsam Parham Sept. 10, 2021

Sept. 10, 2021

=======

3 2

Timezone change detection
by Edward Tomasz Napierała Sept. 4, 2021

Sept. 4, 2021

Hello. I'm working on upstreaming a patch, which originally came from NetApp, to modify localtime.c to automatically detect changes to the time zone. The use case is to make the applications handle moving between timezones, or changing the default system timezone. The idea is pretty simple: just stat(2) the timezone file inode to make sure it still refers to the same file it previously did, and make sure to do this at most once per minute. The patch (with the FreeBSD-specific build glue stripped) follows; previous discussion can be found at https://reviews.freebsd.org/D30183. The patch was written for FreeBSD version of localtime.c, which differs a bit from upstream, but as there seems to be an effort underway to sync FreeBSD with upstream, I believe it also makes sense to ask for comments here before commiting it to FreeBSD. Any feedback is welcome. Thanks :-) diff --git a/contrib/tzcode/stdtime/localtime.c b/contrib/tzcode/stdtime/localtime.c index e221c1fa396..926b24470e1 100644 --- a/contrib/tzcode/stdtime/localtime.c +++ b/contrib/tzcode/stdtime/localtime.c @@ -354,6 +354,45 @@ settzname(void) } } +#ifdef DETECT_TZ_CHANGES +/* + * Determine if there's a change in the timezone since the last time we checked. + * Returns: -1 on error + * 0 if the timezone has not changed + * 1 if the timezone has changed + */ +static int +change_in_tz(const char *name) +{ + static char old_name[PATH_MAX]; + static struct stat old_sb; + struct stat sb; + int error; + + error = stat(name, &sb); + if (error != 0) + return -1; + + if (strcmp(name, old_name) != 0) { + strlcpy(old_name, name, sizeof(old_name)); + old_sb = sb; + return 1; + } + + if (sb.st_dev != old_sb.st_dev || + sb.st_ino != old_sb.st_ino || + sb.st_ctime != old_sb.st_ctime || + sb.st_mtime != old_sb.st_mtime) { + old_sb = sb; + return 1; + } + + return 0; +} +#else /* !DETECT_TZ_CHANGES */ +#define change_in_tz(X) 0 +#endif /* !DETECT_TZ_CHANGES */ + static int differ_by_repeat(const time_t t1, const time_t t0) { @@ -379,6 +418,7 @@ register const int doextend; int stored; int nread; int res; + int ret; union { struct tzhead tzhead; char buf[2 * sizeof(struct tzhead) + @@ -427,6 +467,22 @@ register const int doextend; (void) strcat(fullname, name); name = fullname; } + if (doextend == TRUE) { + /* + * Detect if the timezone file has changed. Check + * 'doextend' to ignore TZDEFRULES; the change_in_tz() + * function can only keep state for a single file. + */ + ret = change_in_tz(name); + if (ret <= 0) { + /* + * Returns -1 if there was an error, + * and 0 if the timezone had not changed. + */ + free(fullname); + return ret; + } + } if ((fid = _open(name, OPEN_MODE)) == -1) { free(fullname); return -1; @@ -1209,12 +1265,43 @@ gmtload(struct state *const sp) (void) tzparse(gmt, sp, TRUE); } +#ifdef DETECT_TZ_CHANGES +static int +recheck_tzdata() +{ + static time_t last_checked; + struct timespec now; + time_t current_time; + int error; + + /* + * We want to recheck the timezone file every 61 sec. + */ + error = clock_gettime(CLOCK_MONOTONIC, &now); + if (error <= 0) { + /* XXX: Can we somehow report this? */ + return 0; + } + + current_time = now.tv_sec; + if ((current_time - last_checked > 61) || + (last_checked > current_time)) { + last_checked = current_time; + return 1; + } + + return 0; +} +#else /* !DETECT_TZ_CHANGES */ +#define recheck_tzdata() 0 +#endif /* !DETECT_TZ_CHANGES */ + static void tzsetwall_basic(int rdlocked) { if (!rdlocked) _RWLOCK_RDLOCK(&lcl_rwlock); - if (lcl_is_set < 0) { + if (lcl_is_set < 0 && recheck_tzdata() == 0) { if (!rdlocked) _RWLOCK_UNLOCK(&lcl_rwlock); return;

5 10

New tzexplorer.org website
by Kerry Shetline Sept. 2, 2021

Sept. 2, 2021

I’ve created a new website, http://tzexplorer.org <http://tzexplorer.org/>, that makes it easy to do conversions among IANA timezones and other time standards like TAI, view the history of time transitions in any timezone, and download TZ code and data in .zip format. There are also links to open-source JavaScript code for the related data/time library, timezone compiler, and Angular components. Please let me know what you think, and if you have any suggestions for changes or additions to the website.

3 2

tz-announce GPG key renewed
by Paul Eggert Sept. 2, 2021

Sept. 2, 2021

The GPG key I use in tz-announce notices expired on August 31. I renewed it for another five years, and the renewed version is appended to this email. Copies of the key are also available for download from my UCLA home directory <https://www.cs.ucla.edu/~eggert/public-key.gpg> and from my Savannah.gnu.org web page <https://savannah.gnu.org/users/eggert>. -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBEyAcmQBEADAAyH2xoTu7ppG5D3a8FMZEon74dCvc4+q1XA2J2tBy2pwaTqf hpxxdGA9Jj50UJ3PD4bSUEgN8tLZ0san47l5XTAFLi2456ciSl5m8sKaHlGdt9Xm AAtmXqeZVIYX/UFS96fDzf4xhEmm/y7LbYEPQdUdxu47xA5KhTYp5bltF3WYDz1Y gd7gx07Auwp7iw7eNvnoDTAlKAl8KYDZzbDNCQGEbpY3efZIvPdeI+FWQN4W+kgh y+P6au6PrIIhYraeua7XDdb2LS1en3SsmE3QjqfRqI/A2ue8JMwsvXe/WK38Ezs6 x74iTaqI3AFH6ilAhDqpMnd/msSESNFt76DiO1ZKQMr9amVPknjfPmJISqdhgB1D lEdw34sROf6V8mZw0xfqT6PKE46LcFefzs0kbg4GORf8vjG2Sf1tk5eU8MBiyN/b Z03bKNjNYMpODDQQwuP84kYLkX2wBxxMAhBxwbDVZudzxDZJ1C2VXujCOJVxq2kl jBM9ETYuUGqd75AW2LXrLw6+MuIsHFAYAgRr7+KcwDgBAfwhPBYX34nSSiHlmLC+ KaHLeCLF5ZI2vKm3HEeCTtlOg7xZEONgwzL+fdKo+D6SoC8RRxJKs8a3sVfI4t6C nrQzvJbBn6gxdgCu5i29J1QCYrCYvql2UyFPAK+do99/1jOXT4m2836j1wARAQAB tCBQYXVsIEVnZ2VydCA8ZWdnZXJ0QGNzLnVjbGEuZWR1PokCVQQTAQgAPwIbAwYL CQgHAwIGFQgCCQoLBBYCAwECHgECF4AWIQR+N5Kp2Kz31jO8FYjtl+kOYqp+NAUC YTAc/AUJHhWsGAAKCRDtl+kOYqp+NBKwD/9Qise9/wZsD8Nyl+ADOCIAFZY5qlSl /5SyCjJIRc6cx/Z0fm4yJVH2Tf3GlSBk1uW24z8+mB2ZxFQUGjio/2iDndSqxYR4 qvPGudo4RGvdvhw6LLqTdRsAY4947xLpNUO6gDtZsRpn4isn+ViX85XfGJrIFjBm zj70eMxEZZrz1IMfUB5I/2oNGDsXDZlCUU30RFMYChGA1ofpIHWdAs+lW2jVBfeE Lbi2su+oUpqrx83u0eJQg3RY3jmPjw8snHS4ieXpvS0e89qziBlNCqS59qJHaf4G XCjz+o5gap2e0NEeQYqcyCqAfqjI78KEpVJNQx5D/zSOvnNs6KuzWD7No4nb5A3p A6KA1JAwJW0H3F2+RhTEg+kFxpcCen0jjuFBnE3TfO3RSpSGqZN0j4AkuR6h/+I7 uUfaQAAope4mso/9VBEElaHYTQmA/m4/AXb2Kt/qkt6QgUIyJtSKcMCVTbfL6iIj rzu4EzkjtZJkbAfvU8lpkUsWX2Qwo25MwyxyzsHMUq9ccIRPEiI0hVu7jeFAql6c ql/3KUWvSr8QCyn7KWhfxyzy6j0+2xtQ29LHAOhboawJJoZd+PtintzHSSZ6G+8T Xn3EbjmHHlXWWfnvWyaJCuJzf1PybRgNYqL6EXCHRHCIb4S9Av8sJpJzZiskG1v5 WUkv79aHb1ol14kCHAQQAQIABgUCVi604AAKCRDNVPzj2WS++xxpD/4hZPbOUfcF LwePuSD3tqKrcmAq0vmyND1aNSOht0OlUbnHtsWxJmThEVEF25VfPbWhD+DZjRj8 hkQNzgkdeLJXJNj8JqS/MedrVa3j3wzHAnSt6fIQ8VvLmZDYg2gCpZrlU/y15Oby OrPkgOCC6MC2PFwHnEpAfR0d6AdbZ+ZeLqbvkB/tkMsqroNMSlPtgq8AWCKX++WJ TBpSw0o/iZjNkq7jW/BWgEVn51oTH8mgS2QN7mxltlaGG3x0AINjKcawfTX+lPks dZ5h9Fy+2QD9MoeAoEKsrS1zFYSVAVwrVAGwvAvz7sFxYzAh0Z+IO80Vwvm8VWfK rKr+483dzR7MzqfQyuCfMwEWg+hQ8r26qCRbe5KgNozVLsV3f1Sj5PwwnT5KE7jg ikYHGk+kSti1V/PiiKfCn9VAHvDad4P+o11R7aH4PaoZYb0M+S7FmKaQfeWcpymH LmpfG8JA7MCsQY0U7ix2jYHIjRZZgolYJ8T2JFf4VlzhiwsMwFNycPqNmGHF4da1 dm248ugKqLFls2aVdb9mTlFYrUQOtLN/FizELEv8dXt4A1bjoK9pO1ZFwffgfP5a fmFjHMSX6Z3KcXGmXZ1tYQocco7S4J4PyERGFhTyT7skXIzuml59+2G4WxGiatJI 3hhxaN0237vot5sIVDl1TpCMLr/02+qKfbkCDQRMgHJkARAApoXrvxP3DIfjCNOt XU/PdwMShKdX/RlSs5PfunV1wbKP8herXHrvQdFVqECaTSxmlhzbk8X0PkY9gcVa U2O49T3qsOd1cHeF52YFGEt0LhsBeMjgNX5uZ1V76r8gyeVlFpWWb0SIwJUBHrDX exF67upeRb2vdHBjYDNeySn+0B7gFEqvVmZu+LadudDp6kQLjatFvHQHUSGNshBn kkcaTbiI9Pst0GCc2aiznBiPPA2WQxAPlPRh3OGTsn5THADmbjqY6FEMLasVX8DS CblMvLwNeO/8SxziBidhqLpJCqdQRWHku5XxgIkGeKOz5OLDvXHWJyafrEYjjkS6 Ak6B5z6svKliClWnjHQcjlPzyoFFgKTEfcqDxCj4RY0D0DgtFD0NfyeOidrSB/Sz Te2hwryQE3rpSiqo+0cGdzh4yAHKYJ+UrXZ4p93ZhjGfKD1xlrNYDlWyW9PGmbvq FuDmiIAQf9WD/wzEfICc+F+uDDI+uYkRxUFp92ykmdhDEFg1yjYsU8iGU69aHyvh q36z4zctvbqhRNzOWB1bVJ/dIMDvsExGcXQVDIT7sDNXv0wE3jKSKpp7NDG1oXUX L+2+SF99Kjy753AbQSAmH617fyBNwhJWvQYg+mUvPpiGOtses9EXUI3lS4v0MEaP G43flEs1UR+1rpFQWVHo1y1OO+sAEQEAAYkCPAQYAQgAJgIbDBYhBH43kqnYrPfW M7wViO2X6Q5iqn40BQJhMB1RBQkeFaxtAAoJEO2X6Q5iqn40d5QP/iRm1LyrCKbM dqgP9ShOcPH7UfFEr4SY2TDdQgE4L+QItP16RNgTxAkxaBxK95I0nletr03inRKw sb0dIw/BH2LXbG2DjI6yKJK6UThVhWWBXYuGjSv2i6bVIzHLRY3IOQF+8dyVJ+vo eaOtxdV1lYR1ke/Dv6pFqUGGNBsSVu/2R03uCffTA9OsRzbuV5mJrFgxVFmBAguL N/cT5Ffh77x3LsA61Ro3hIX4399GFFBQ3h4RfMA1nNWiU0KjNy/GtW0amxn26zhq Qvy0W0hEJRA6ts+e/4ZHwcX3U7NTnPTckbCyy71d7U8/AVHkoy7EB8ROcDbJHTJc KlG9f6eYlPZ2aYVqBd9n1Yj4NYT1zobrQjvHQRCUAx0naKscN2es9x/rWvg4BnnB cXRaT2a8Wy3pKzLGD61dstvUM7tnyvdBxHk7aLlbdsfZP+flP2tbHkFNZWH5myPE lPMcQGFYyi9to+4YZU28G3rnzxmKFWkYAEMaxPZPunOZnOBHURFhgk/qs6GYSTPv g0u/kd1JV2yOKHb8+SB/Dpk/gx9KybTUC3TtbW1b2X94ErB8LCmpMi26a3ZvyxrE 5DJx2GdUoj2QkKTSFQV7MOo1tJ9vwtSfHnpT/+E6yKtzCLl9CNiVjd57puN1BhWC VvLwfAzUC2UvpPYh8u3maJaMAC6BgK78 =JpE/ -----END PGP PUBLIC KEY BLOCK-----

1 0

tzcode: uninitialized sp->charcnt gives clang analyzer warning
by Jan Engelhardt Aug. 11, 2021

Aug. 11, 2021

When building tzcode commit 7f74206b39673b1a110285c6992f70507e211060 with -DALL_STATE, clang reports a loop with a undefined termination condition because sp->charcnt is not set before its use. There should probably be a sp->charcnt=0 in zoneinit. >> clang --analyze -Xanalyzer -analyzer-output=text localtime.c -DALL_STATE localtime.c:321:16: warning: The right operand of '<' is a garbage value [core.UndefinedBinaryOperatorResult] for (i = 0; i < sp->charcnt; ++i) ^ localtime.c:2210:7: note: 'err' is 0 if (err) { ^~~ localtime.c:2210:3: note: Taking false branch if (err) { ^ localtime.c:2214:3: note: Calling 'tzset_unlocked' tzset_unlocked(); ^~~~~~~~~~~~~~~~ localtime.c:1383:13: note: Assuming 'name' is null int lcl = name ? strlen(name) < sizeof lcl_TZname : -1; ^~~~ localtime.c:1383:13: note: '?' condition is false localtime.c:1384:7: note: 'lcl' is < 0 if (lcl < 0 ^~~ localtime.c:1384:7: note: '?' condition is true localtime.c:1385:9: note: Assuming 'lcl_is_set' is >= 0 ? lcl_is_set < 0 ^~~~~~~~~~~~~~ localtime.c:1384:3: note: Taking false branch if (lcl < 0 ^ localtime.c:1389:7: note: Assuming 'sp' is null if (! sp) ^~~~ localtime.c:1389:3: note: Taking true branch if (! sp) ^ localtime.c:1390:19: note: Uninitialized value stored to field 'charcnt' lclptr = sp = malloc(sizeof *lclptr); ^~~~~~~~~~~~~~~~~~~~~~ localtime.c:1392:7: note: Assuming 'sp' is non-null if (sp) { ^~ localtime.c:1392:3: note: Taking true branch if (sp) { ^ localtime.c:1393:9: note: Calling 'zoneinit' if (zoneinit(sp, name) != 0) ^~~~~~~~~~~~~~~~~~ localtime.c:1355:7: note: 'name' is null if (name && ! name[0]) { ^~~~ localtime.c:1355:12: note: Left side of '&&' is false if (name && ! name[0]) { ^ localtime.c:1369:15: note: Calling 'tzload' int err = tzload(name, sp, true); ^~~~~~~~~~~~~~~~~~~~~~ localtime.c:739:7: note: Assuming 'lsp' is null if (!lsp) ^~~~ localtime.c:739:3: note: Taking true branch if (!lsp) ^ localtime.c:740:5: note: Returning without writing to 'sp->charcnt' return errno; ^ localtime.c:1369:15: note: Returning from 'tzload' int err = tzload(name, sp, true); ^~~~~~~~~~~~~~~~~~~~~~ localtime.c:1370:9: note: Assuming 'err' is equal to 0 if (err != 0 && name && name[0] != ':' && tzparse(name, sp, NULL)) ^~~~~~~~ localtime.c:1370:18: note: Left side of '&&' is false if (err != 0 && name && name[0] != ':' && tzparse(name, sp, NULL)) ^ localtime.c:1372:9: note: 'err' is equal to 0 if (err == 0) ^~~ localtime.c:1372:5: note: Taking true branch if (err == 0) ^ localtime.c:1373:7: note: Calling 'scrub_abbrs' scrub_abbrs(sp); ^~~~~~~~~~~~~~~ localtime.c:321:16: note: The right operand of '<' is a garbage value for (i = 0; i < sp->charcnt; ++i) ^ ~~~~~~~~~~~ localtime.c:1277:4: warning: Value stored to 'theiroffset' is never read [deadcode.DeadStores] theiroffset = theirstdoffset; ^ ~~~~~~~~~~~~~~ localtime.c:1277:4: note: Value stored to 'theiroffset' is never read theiroffset = theirstdoffset; ^ ~~~~~~~~~~~~~~ 2 warnings generated.

5 11

No leap second on 2021-12-31
by Tim Parenti July 22, 2021

July 22, 2021

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 ---------- Forwarded message --------- From: IERS EOP Product Center <iers.eoppc(a)obspm.fr> Date: Mon, 5 Jul 2021 at 05:54 Subject: Bulletin C number 62 To: <bulc.iers(a)obspm.fr> INTERNATIONAL EARTH ROTATION AND REFERENCE SYSTEMS SERVICE (IERS) SERVICE INTERNATIONAL DE LA ROTATION TERRESTRE ET DES SYSTEMES DE REFERENCE SERVICE DE LA ROTATION TERRESTRE DE L'IERS OBSERVATOIRE DE PARIS 61, Av. de l'Observatoire 75014 PARIS (France) Tel. : +33 1 40 51 23 35 e-mail : services.iers(a)obspm.fr http://hpiers.obspm.fr/eop-pc Paris, 05 July 2021 Bulletin C 62 To authorities responsible for the measurement and distribution of time INFORMATION ON UTC - TAI NO leap second will be introduced at the end of December 2021. The difference between Coordinated Universal Time UTC and the International Atomic Time TAI is : from 2017 January 1, 0h UTC, until further notice : UTC-TAI = -37 s Leap seconds can be introduced in UTC at the end of the months of December or June, depending on the evolution of UT1-TAI. Bulletin C is mailed every six months, either to announce a time step in UTC, or to confirm that there will be no time step at the next possible date. Christian BIZOUARD Director Earth Orientation Center of IERS Observatoire de Paris, France

1 0