- tz - lists.iana.org

[PROPOSED 1/2] Omit duplicate Link lines in ziguard output
by Paul Eggert May 10, 2021

May 10, 2021

* ziguard.awk: Later Link lines now comment out earlier ones. Formerly, we relied on ‘zic’ to ignore the earlier lines, but this made for more-confusing ziguard output. This change does not affect zic’s output. --- ziguard.awk | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/ziguard.awk b/ziguard.awk index 7d6f7c9..6888c27 100644 --- a/ziguard.awk +++ b/ziguard.awk @@ -114,15 +114,16 @@ DATAFORM != "main" { } } -# If a Link line is followed by a Zone line for the same data, comment +# If a Link line is followed by a Link or Zone line for the same data, comment # out the Link line. This can happen if backzone overrides a Link -# with a Zone. -/^Link/ { - linkline[$3] = NR -} +# with a Zone or a different Link. /^Zone/ { sub(/^Link/, "#Link", line[linkline[$2]]) } +/^Link/ { + sub(/^Link/, "#Link", line[linkline[$3]]) + linkline[$3] = NR +} { line[NR] = $0 } -- 2.27.0

1 1

JavaScript IANA date/time library, now with support for leap seconds, TAI, TDT
by Kerry Shetline April 29, 2021

April 29, 2021

About two months ago I released the first major version of @tubular/time, a JavaScript/TypeScript npm package for date/time handling, with solid support for IANA timezones, including dealing with weird edge cases like 47-hour days and negative DST and such. I’ve just finished up adding a feature I’ve always wanted to have in a date/time package, and that’s the ability to properly handle and represent leap seconds. Along with that comes conversion to and from TAI (International Atomic Time) and astronomical time systems. https://www.npmjs.com/package/@tubular/time One interesting issue was how to handle a broad range of years (thousands of years forward and backward in time) in a way that was nicely integrated with Universal Coordinated Time. The idea for UTC got something of a wobbly start around 1960, and wasn’t implemented in its current form until 1972. Going forward in time, UTC is only strictly defined for up to six months beyond the next announced leap second, or next announced lack of any leap second on the way. I settled on the following scheme for resolving these issues, and I’m curious what others might think about it: * For all dates prior to 1957, estimated UT1 is in effect. This is most accurate back to 1600, for which there is sufficient astronomical data for reasonable approximate conversions from UT1 to TAI and dynamical time. Further back in time less accurate approximations are in effect. * From 1957-1958, using a sliding weighted average, UT1 transitions to proleptic UTC. * From 1958-1972 proleptic UTC, as proposed by Tony Finch (https://fanf.livejournal.com/69586.html) is used, with the first non-official leap second occurring at 1959-06-30 23:59:60. * From 1972 up until the latest updates provided by the International Bureau of Weights and Measures, well-defined UTC prevails, with the first official leap second occurring at 1972-06-30 23:59:60. * For a year to 18 months after the current time, or after the last defined leap second (whichever is later), a presumed leap-second-free span of UTC is projected to occur. * A sliding weighted average transition from UTC to estimated UT1 follows for the next 365 days. * Formulaic predicted UT1 is used for all later dates and times thereafter. Another project I’ve been working on (which isn’t quite ready for prime time because it’s utterly without documentation) is a new JavaScript timezone compiler. This has replaced an old Java project I used for generating the timezone data used by @tubular/time: https://github.com/kshetline/tubular_time_tzdb

7 16

Re: [tz] JavaScript IANA date/time library, now with support for leap seconds, TAI, TDT
by Kerry Shetline April 27, 2021

April 27, 2021

On Mon, 26 Apr 2021 16:03:59 -0400, John_Sauter via tz wrote: > Based on the way the Earth has been rotating recently, the next leap > second will be around the end of this decade, and it will be a negative > leap second. What kind of hopeless nerd does it make me that I find this an exciting prospect? I’ve taken negative leap seconds to be a nearly completely hypothetical idea, even though I have nevertheless coded diligently to account for the possibility.

2 1

Re: [tz] JavaScript IANA date/time library, now with support for leap seconds, TAI, TDT
by Kerry Shetline April 27, 2021

April 27, 2021

On Mon, 26 Apr 2021 15:06:12 -0600, Paul Gilmartin <PaulGBoulder(a)aim.com> wrote: >> POSIX time is really just UTC without the leap seconds, isn?t it? >> > More precisely, POSIX time counts non-leap seconds since 1972-01-01t00:00:00 UTC. That would be 1970-01-01T00:00:00 UTC. 1972 is, however, the year that the first official leap second (for POSIX not to count) occurred.

1 1

Re: [tz] JavaScript IANA date/time library, now with support for leap seconds, TAI, TDT
by Steve Allen April 26, 2021

April 26, 2021

On Mon 2021-04-26T17:17:13+0100 Tony Finch via tz hath writ: > My aim back then was to sketch what might be a reasonable way to bridge > between pre-atomic time and UTC, for code that can only support an integer > offset between UTC and TAI. If your code supports rubber seconds then it > should probably use the USNO table that records the rate and phase offsets > between 1962 and 1972. (I don't know another source of that table, nor > where you can get a copy while maia.usno.navy.mil is down.) Keep in mind that the USNO numbers only apply to time signals broadcast in the US, and before 1968 they ignore the many microseconds of offset between NBS and USNO. Germany did not start to broadcast the old UTC until the late 1960s, until 1974-01-01 broadcast both old UTC and SAT, and stopped providing old UTC as of 1970-04-01 because it had been deemed illegal. Soviet and Chinese time signals never used the old UTC. Sussing out the particulars for individual cases of national time signals needs finding remnants of the high-acid paper that each national time service used for bulletins issued to its users, and/or diving through the BIH Bulletin Horaire and Circular D to pull out the received timing of each official broadcast. It is much simpler to ignore the 50 to 200 ms jumps that were put into old UTC and say that before 1972 all available sources of civil time provided UT (nevermind the particular flavor, nobody set their clock that accurately) and after 1972 UTC with leap seconds. For civil time I do not see any advantage in a model with greater complexity than just plain UT as the basis time scale before 1972-01-01. This is adequate for any IANA tz library. For precise time no general model applies. Each precise timestamp must be meticulously referenced to the particulars of the clocks that were used to obtain it. No available clocks were using TAI before 1972-01-01, and this does not belong in any IANA tz library. Constructing a model that supposes it is possible to do better is akin to writing The Silmarillion. Look at the BIH plots of the accuracy of clocks https://www.ucolick.org/~sla/leapsecs/BHsHn05p142.html millisecond agreement between different national authorities was not achieved until 1960 during the UK/US experiment that became old UTC. > * TAI is a retrospective timescale; it isn't defined in the future. TAI also cannot be defined prior to mid 1955, and it was not generally availble for use by any system until 1972-01-01 when broadcast time signals began to be based on TAI. The BIPM will never tolerate TAI becoming part of an international agreement. The best that can be hoped for in a new international agreement on time is one (or more) new TAI-like uniform scale which will be offset by some integer number of seconds from TAI. The reason we use UTC is because it is what is in the current international agreement. Everybody involved in the technical aspects eschewed the use of UTC for their systems from before 1972-01-01. Look at the ATSC agreement for a technically-competent time scale. They chose GPS time because it is practically available. ATSC was not bound by international bureaucratic requirements, so they could make that choice. Because it is ultimately controlled by USNO GPS system time will never become part of an international agreement. On Mon 2021-04-26T12:42:19-0400 John Sauter via tz hath writ: > In looking at historical estimates of the rotation of the Earth based > on astronomical observations of occulations and eclipses, I found that > the values of UT1 are reliabe only since 1825. (Nevertheless, my table > of proleptic leap seconds goes back to the year -2000.) Morrison, L. V.; Stephenson, F. R.; Hohenkerk, C. Y.; Zawilski, M. DOI: 10.1098/rspa.2020.0776 Bibliographic Code: 2021RSPSA.47700776M Proceedings of the Royal Society A, Volume 477, Issue 2246, id.20200776 all tabulated at http://astro.ukho.gov.uk/nao/lvm/ That is the place to look, and it will continue to be so for the lifetime of the authors. But what is it mean to ask reliable? That is very much the question given that prior to "reliable" everybody's clock was set to local apparent time. What exactly is the question that is trying to be answered by an algorithm like this? Ultimately it is necessary to model two kinds of time: 1) earth rotation time (which before the 20th century differed by a second or more depending on who was setting the clock) because that is a subdivision of internationally agreed calendar days 2) uniform time (which becomes possible to interpret as atomic time beginning in 1955). -- Steve Allen <sla(a)ucolick.org> WGS-84 (GPS) UCO/Lick Observatory--ISB 260 Natural Sciences II, Room 165 Lat +36.99855 1156 High Street Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 https://www.ucolick.org/~sla/ Hgt +250 m

3 3

[PROPOSED] Do not assume bytes have 8 bits
by Paul Eggert April 26, 2021

April 26, 2021

* zic.c (convert, convert64): Mask bytes with 0xff before storing them, for portability to machines where bytes have more than 8 bits. Although this is surely only of theoretical interest, we might as well be portable. --- zic.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/zic.c b/zic.c index 88b1531..77a5698 100644 --- a/zic.c +++ b/zic.c @@ -1927,7 +1927,7 @@ convert(uint_fast32_t val, char *buf) unsigned char *const b = (unsigned char *) buf; for (i = 0, shift = 24; i < 4; ++i, shift -= 8) - b[i] = val >> shift; + b[i] = (val >> shift) & 0xff; } static void @@ -1938,7 +1938,7 @@ convert64(uint_fast64_t val, char *buf) unsigned char *const b = (unsigned char *) buf; for (i = 0, shift = 56; i < 8; ++i, shift -= 8) - b[i] = val >> shift; + b[i] = (val >> shift) & 0xff; } static void -- 2.27.0

4 5

[PATCH] Fix potential integer overflow in differ_by_repeat
by Paul Eggert April 26, 2021

April 26, 2021

* localtime.c (differ_by_repeat): Remove, since the subtraction t1 - t0 could in theory overflow in 64-bit TZif data. (tzloadbody): Redo to avoid integer overflow. * private.h (SECSPERREPEAT_BITS): Remove; no longer used. --- localtime.c | 30 ++++++++++++++---------------- private.h | 3 +-- 2 files changed, 15 insertions(+), 18 deletions(-) diff --git a/localtime.c b/localtime.c index 9dd496d..9840b89 100644 --- a/localtime.c +++ b/localtime.c @@ -334,14 +334,6 @@ scrub_abbrs(struct state *sp) } } -static bool -differ_by_repeat(const time_t t1, const time_t t0) -{ - if (TYPE_BIT(time_t) - TYPE_SIGNED(time_t) < SECSPERREPEAT_BITS) - return 0; - return t1 - t0 == SECSPERREPEAT; -} - /* Input buffer for data read from a compiled tz file. */ union input_buffer { /* The first part of the buffer, interpreted as a header. */ @@ -660,20 +652,26 @@ tzloadbody(char const *name, struct state *sp, bool doextend, if (sp->typecnt == 0) return EINVAL; if (sp->timecnt > 1) { + if (sp->ats[0] <= TIME_T_MAX - SECSPERREPEAT) { + time_t repeatat = sp->ats[0] + SECSPERREPEAT; + int repeattype = sp->types[0]; for (i = 1; i < sp->timecnt; ++i) - if (typesequiv(sp, sp->types[i], sp->types[0]) && - differ_by_repeat(sp->ats[i], sp->ats[0])) { + if (sp->ats[i] == repeatat + && typesequiv(sp, sp->types[i], repeattype)) { sp->goback = true; break; - } + } + } + if (TIME_T_MIN + SECSPERREPEAT <= sp->ats[sp->timecnt - 1]) { + time_t repeatat = sp->ats[sp->timecnt - 1] - SECSPERREPEAT; + int repeattype = sp->types[sp->timecnt - 1]; for (i = sp->timecnt - 2; i >= 0; --i) - if (typesequiv(sp, sp->types[sp->timecnt - 1], - sp->types[i]) && - differ_by_repeat(sp->ats[sp->timecnt - 1], - sp->ats[i])) { + if (sp->ats[i] == repeatat + && typesequiv(sp, sp->types[i], repeattype)) { sp->goahead = true; break; - } + } + } } /* Infer sp->defaulttype from the data. Although this default diff --git a/private.h b/private.h index cee3b11..340a354 100644 --- a/private.h +++ b/private.h @@ -642,7 +642,7 @@ time_t time2posix_z(timezone_t, time_t) ATTRIBUTE_PURE; #define TIME_T_MAX_NO_PADDING MAXVAL(time_t, TYPE_BIT(time_t)) /* The extreme time values. These are macros, not constants, so that - any portability problem occur only when compiling .c files that use + any portability problems occur only when compiling .c files that use the macros, which is safer for applications that need only zdump and zic. This implementation assumes no padding if time_t is signed and either the compiler lacks support for _Generic or time_t is not one @@ -727,7 +727,6 @@ char *ctime_r(time_t const *, char *); #define YEARSPERREPEAT 400 /* years before a Gregorian repeat */ #define DAYSPERREPEAT ((int_fast32_t) 400 * 365 + 100 - 4 + 1) #define SECSPERREPEAT ((int_fast64_t) DAYSPERREPEAT * SECSPERDAY) -#define SECSPERREPEAT_BITS 34 /* ceil(log2(SECSPERREPEAT)) */ #define AVGSECSPERYEAR (SECSPERREPEAT / YEARSPERREPEAT) #define TM_SUNDAY 0 -- 2.27.0

1 0

[PROPOSED 1/2] Do not assume unsigned->signed conversion style
by Paul Eggert April 23, 2021

April 23, 2021

* localtime.c (detzcode64): Use int_fast64_t, not uint_fast64_t, for local variable, to avoid an implementation-defined conversion when the variable’s value is returned. --- localtime.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/localtime.c b/localtime.c index 6c88b6e..9dd496d 100644 --- a/localtime.c +++ b/localtime.c @@ -237,7 +237,7 @@ detzcode(const char *const codep) static int_fast64_t detzcode64(const char *const codep) { - register uint_fast64_t result; + register int_fast64_t result; register int i; int_fast64_t one = 1; int_fast64_t halfmaxval = one << (64 - 2); -- 2.27.0

1 1

[PROPOSED 1/2] * SECURITY: New file.
by Paul Eggert April 20, 2021

April 20, 2021

--- SECURITY | 15 +++++++++++++++ 1 file changed, 15 insertions(+) create mode 100644 SECURITY diff --git a/SECURITY b/SECURITY new file mode 100644 index 0000000..40128bc --- /dev/null +++ b/SECURITY @@ -0,0 +1,15 @@ +Please report any sensitive security-related bugs via email to the +tzdb designated coordinators, currently Paul Eggert +<eggert(a)cs.ucla.edu> and Tim Parenti <tim(a)timtimeonline.com>. +Put "tzdb security" at the start of your email's subject line. +We prefer communications to be in English. + +You should receive a response within a week. If not, please follow up +via email to make sure we received your original message. + +If we confirm the bug, we plan to notify affected third-party services +or software that we know about, prepare an advisory, commit fixes to +the main development branch as quickly as is practical, and finally +publish the advisory on tz(a)iana.org. As with all tzdb contributions, +we give credit to security contributors unless they wish to remain +anonymous. -- 2.27.0

1 1

Wisconsin daylight savings 1957
by TJ April 17, 2021

April 17, 2021

Hey everyone, I was doing some digging and found the following referendum in 1957 for Wisconsin. - https://ballotpedia.org/Wisconsin_Daylight_Saving_Time,_Question_1_(April_1… The text of the measure that passed was: "Shall section 175.095 (2) of the statutes, which proposes a statewide daylight saving time of one hour per day from the last Sunday in April to the last Sunday in September in each year be law beginning with the last Sunday in April 1957?" However, the 1947 ballot to use daylight savings was defeated: https://ballotpedia.org/Wisconsin_Daylight_Saving_Time_Referendum,_Question… In the tz db for North America, it looks like Wisconsin is using America/Chicago which has a few rules for the time period in question: Rule Chicago 1922 1954 - Sep lastSun 2:00 0 S Rule Chicago 1955 1966 - Oct lastSun 2:00 0 S It appears to me that Wisconsin might need some modification? Is this the correct mailing list for this discussion? Thanks, TJ

3 3