- tz - lists.iana.org

Questions on tzname and tm_zone
by Patrik Lantto Dec. 31, 2022

Dec. 31, 2022

Dear all, I have a few questions regarding how the tzdb code handles tzname and tm_zone: * The define HAVE_TZNAME have three different "settings"; 0 if tzname is not supported, 1 to support tzname defined by the system library and 2 to support and define tzname. In the code though, when defining tzname it also adds the value of TZ_TIME_T which reduces the options. Basically, if time_tz is defined to another datatype that time_t, tzname cannot be defined by the system library since setting HAVE_TZNAME to 1 would still define tzname (around line 195 of localtime.c). Is there a reason for this behaviour (which is also similar for USG_COMPAT)? In my platform we define a new 64 bit datatype, but would still need tzname as defined by the system library. * In case of an invalid timezone, the behaviour of tzname and tm_zone behaves differently; tzname would be set to WILDABBR (which is possible to define), but if localtime is called tm_zone will be set to "UTC" while if gmtime is called, tm_zone is set to "-00" and if offtime is called (with a non-0 offset) tm_zone is WILDABBR. It seems somewhat inconsistent, so is this by design? * The way tzname is updated (in settzname) in settzname is that it first set tzname[0] and tzname[1] to either WILDABBR or UTC, and then possibly update with the correct names. While tzname is not considered thread safe, this way writing to tzname twice means that even call to tzset with the same timezone could affect other threads reading tzname. Not a huge risk, but still possible. Is this something to consider in the implementation? * Since tzname is not thread safe, and due to the way tm_zone is handled it is somewhat hard to detect if a TZ string is valid or not. Is there a recommended way to detect an invalid string? Best regards, Patrik Lantto -- Patrik Lantto - patrik.lantto(a)wisi.se - +46 13 210918

2 1

[PROPOSED] Support leap-seconds.list tombstone
by Paul Eggert Dec. 23, 2022

Dec. 23, 2022

From: Paul Eggert <eggert@trombone> This change looks forward to the possibility of leap seconds being discontinued by 2035. If and when that happens, the expiration date on the leap-seconds.list file is likely to stop being maintained, as there will be no need to issue new versions of leap-seconds.list every six months. Although the details have not been decided, for now assume that the last edition of leap-seconds.list will simply lack an expiration-date line. * leapseconds.awk: If the input lacks an expiration line like ‘#@ 3896899200’, do not treat it as if ‘#@ 0’ were present, as that would mean an expiration date of 1900-01-01. Instead, do not output an expiration date; just output a comment saying that there is no expiration date. Similarly for update dates and input lacking lines like ’#$ 3676924800’. --- NEWS | 3 +++ leapseconds.awk | 50 ++++++++++++++++++++++++++++++------------------- 2 files changed, 34 insertions(+), 19 deletions(-) diff --git a/NEWS b/NEWS index 9ac3367..5510823 100644 --- a/NEWS +++ b/NEWS @@ -42,6 +42,9 @@ Unreleased, experimental changes 'restrict' keyword consistently with their documentation. This may allow future optimizations. + leapseconds.awk can now process a leap seconds file that never + expires; this might be useful if leap seconds are discontinued. + Changes to commentary Note that leap seconds are planned to be discontinued by 2035. diff --git a/leapseconds.awk b/leapseconds.awk index b6c48bc..7d2556b 100644 --- a/leapseconds.awk +++ b/leapseconds.awk @@ -104,18 +104,23 @@ BEGIN { } END { - sstamp_to_ymdhMs(expires, ss_NTP) - print "" - print "# UTC timestamp when this leap second list expires." - print "# Any additional leap seconds will come after this." - if (! EXPIRES_LINE) { - print "# This Expires line is commented out for now," - print "# so that pre-2020a zic implementations do not reject this file." + + if (expires) { + sstamp_to_ymdhMs(expires, ss_NTP) + + print "# UTC timestamp when this leap second list expires." + print "# Any additional leap seconds will come after this." + if (! EXPIRES_LINE) { + print "# This Expires line is commented out for now," + print "# so that pre-2020a zic implementations do not reject this file." + } + printf "%sExpires %.4d\t%s\t%.2d\t%.2d:%.2d:%.2d\n", \ + EXPIRES_LINE ? "" : "#", \ + ss_year, monthabbr[ss_month], ss_mday, ss_hour, ss_min, ss_sec + } else { + print "# (No Expires line, since the expires time is unknown.)" } - printf "%sExpires %.4d\t%s\t%.2d\t%.2d:%.2d:%.2d\n", \ - EXPIRES_LINE ? "" : "#", \ - ss_year, monthabbr[ss_month], ss_mday, ss_hour, ss_min, ss_sec # The difference between the NTP and POSIX epochs is 70 years # (including 17 leap days), each 24 hours of 60 minutes of 60 @@ -124,15 +129,22 @@ END { print "" print "# POSIX timestamps for the data in this file:" - sstamp_to_ymdhMs(updated, ss_NTP) - printf "#updated %d (%.4d-%.2d-%.2d %.2d:%.2d:%.2d UTC)\n", \ - updated - epoch_minus_NTP, \ - ss_year, ss_month, ss_mday, ss_hour, ss_min, ss_sec - sstamp_to_ymdhMs(expires, ss_NTP) - printf "#expires %d (%.4d-%.2d-%.2d %.2d:%.2d:%.2d UTC)\n", \ - expires - epoch_minus_NTP, \ - ss_year, ss_month, ss_mday, ss_hour, ss_min, ss_sec - + if (updated) { + sstamp_to_ymdhMs(updated, ss_NTP) + printf "#updated %d (%.4d-%.2d-%.2d %.2d:%.2d:%.2d UTC)\n", \ + updated - epoch_minus_NTP, \ + ss_year, ss_month, ss_mday, ss_hour, ss_min, ss_sec + } else { + print "#(updated time unknown)" + } + if (expires) { + sstamp_to_ymdhMs(expires, ss_NTP) + printf "#expires %d (%.4d-%.2d-%.2d %.2d:%.2d:%.2d UTC)\n", \ + expires - epoch_minus_NTP, \ + ss_year, ss_month, ss_mday, ss_hour, ss_min, ss_sec + } else { + print "#(expires time unknown)" + } printf "\n%s", last_lines } -- 2.38.1

1 0

Re: [tz] [PROPOSED] Mention the planned obsolescence of leap seconds
by Brian Inglis Dec. 22, 2022

Dec. 22, 2022

On 2022-12-20 17:25, Paul Eggert via tz wrote: > + Changes to commentary > + Note that leap seconds are planned to be discontinued by 2035. > + This affects time stamps during the leap second era (1972–2035). > +Leap seconds were introduced in 1972 to accommodate the > +difference between atomic time and the less-regular rotation of the earth. > +Unfortunately they caused so many problems with civil Civil (e.g. legal etc.) time keeping is not the problem, it is mainly proprietary computer systems and applications, not adequately programmed to deal with the realities of time keeping. > +timekeeping that they > +are <a href="https://www.bipm.org/en/cgpm-2022/resolution-4">planned > +to be discontinued by 2035</a>, with some as-yet-undetermined > +mechanism replacing them, perhaps after the year 2135. > +Despite their impending obsolescence, a record of leap seconds is still > +needed to resolve timestamps from 1972 through 2035. I would expect astronomers and physicists to have divergent views, but both use software which handles varieties of time bases, scales, and conversions. It seems likely that other scientists and disciplines with time concerns would line up behind one or the other, depending on whether their focus is civil, geocentric, or longer term in some way, or more artificial on accuracy, calibration, precision or other short term characteristics. > <a href="https://www.ucolick.org/~sla/leapsecs/"><abbr>UTC</abbr> > might be redefined > without Leap Seconds</a> gives pointers on this > +contentious issue. > +The General Conference on Weights and Measures > +<a href="https://www.bipm.org/en/cgpm-2022/resolution-4">voted in 2022</a> > +to discontinue the use of leap seconds by 2035, replacing them with an > +as-yet-undetermined scheme some time after the year 2135. Expect every lawyer, in any case involving time stamped records, to jump on the technicality of any significant deviation of time keeping from solar time, which is the legal basis in most English common law jurisdictions, possibly also in some continental code and Scandinavian/Nordic jurisdictions e.g. Denmark: https://www.dr.dk/nyheder/indland/uret-paa-din-telefon-viser-en-ulovlig-tid https://www-dr-dk.translate.goog/nyheder/indland/uret-paa-din-telefon-viser… -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry

1 0

DST in the news
by Arthur David Olson Dec. 22, 2022

Dec. 22, 2022

A 538 piece on the merits and demerits of permanent standard time and permanent daylight time. https://projects.fivethirtyeight.com/daylight-saving-time/ --ado

1 0

[PROPOSED] Document deprecation of ctime, asctime.
by Paul Eggert Dec. 21, 2022

Dec. 21, 2022

--- newctime.3 | 17 +++++++++++++++-- 1 file changed, 15 insertions(+), 2 deletions(-) diff --git a/newctime.3 b/newctime.3 index e25d841..2790c81 100644 --- a/newctime.3 +++ b/newctime.3 @@ -11,13 +11,13 @@ asctime, ctime, difftime, gmtime, localtime, mktime \- convert date and time .PP .BR "extern char *tzname[];" " /\(** (optional) \(**/" .PP -.B char *ctime(time_t const *clock); +.B [[deprecated]] char *ctime(time_t const *clock); .PP .B char *ctime_r(time_t const *clock, char *buf); .PP .B double difftime(time_t time1, time_t time0); .PP -.B char *asctime(struct tm const *tm); +.B [[deprecated]] char *asctime(struct tm const *tm); .PP .B "char *asctime_r(struct tm const *restrict tm," .B " char *restrict result);" @@ -91,6 +91,15 @@ introduction of UTC and are some other flavor of Universal Time (UT). Some implementations support leap seconds, in contradiction to POSIX. .PP The +.B ctime +function is deprecated starting in C23. +Callers can use +.B localtime_r +and +.B strftime +instead. +.PP +The .B localtime and .B gmtime @@ -128,6 +137,10 @@ converts a time value contained in a structure to a string, as shown in the above example, and returns a pointer to the string. +This function is deprecated starting in C23. +Callers can use +.B strftime +instead. .PP The .B mktime -- 2.38.1

1 0

Windows build failures
by Manuela Friedrich Dec. 21, 2022

Dec. 21, 2022

Hello Paul, I noticed new Windows build failures with the latest tz code from git. Hopefully you can shed some light on these. Error 1 d:\iana\tmp\private.h(704): error C2373: 'restrict': redefinition; different type modifiers d:\iana\tmp\private.h(704): note: see declaration of 'restrict' d:\iana\tmp\private.h(780): error C2373: 'restrict': redefinition; different type modifiers d:\iana\tmp\private.h(780): note: see declaration of 'restrict' d:\iana\tmp\private.h(781): error C2371: 'restrict': redefinition; different basic types d:\iana\tmp\private.h(780): note: see declaration of 'restrict' Error 2 zic.c(154): error C2146: syntax error: missing ')' before identifier 'file' zic.c(154): error C2061: syntax error: identifier 'file' zic.c(154): error C2059: syntax error: ';' zic.c(154): error C2059: syntax error: ',' zic.c(154): error C2059: syntax error: ')' Thank you! Kind Regards Manuela Friedrich

2 5

[PROPOSED] Mention the planned obsolescence of leap seconds
by Paul Eggert Dec. 21, 2022

Dec. 21, 2022

--- NEWS | 4 ++++ theory.html | 15 ++++++++++++++- tz-link.html | 8 ++++++-- 3 files changed, 24 insertions(+), 3 deletions(-) diff --git a/NEWS b/NEWS index 9b2d202..9ac3367 100644 --- a/NEWS +++ b/NEWS @@ -42,6 +42,10 @@ Unreleased, experimental changes 'restrict' keyword consistently with their documentation. This may allow future optimizations. + Changes to commentary + + Note that leap seconds are planned to be discontinued by 2035. + Release 2022g - 2022-11-29 08:58:31 -0800 diff --git a/theory.html b/theory.html index fbbb9e4..88bf720 100644 --- a/theory.html +++ b/theory.html @@ -818,7 +818,8 @@ href="https://www.dissentmagazine.org/blog/booked-a-global-history-of-time-vanes <li> The relationship between POSIX time (that is, <abbr>UTC</abbr> but ignoring <a href="https://en.wikipedia.org/wiki/Leap_second">leap - seconds</a>) and <abbr>UTC</abbr> is not agreed upon after 1972. + seconds</a>) and <abbr>UTC</abbr> is not agreed upon. + This affects time stamps during the leap second era (1972–2035). Although the POSIX clock officially stops during an inserted leap second, at least one proposed standard has it jumping back a second instead; and in @@ -1268,6 +1269,18 @@ between now and the future time. <section> <h2 id="leapsec">Leap seconds</h2> +<p> +Leap seconds were introduced in 1972 to accommodate the +difference between atomic time and the less-regular rotation of the earth. +Unfortunately they caused so many problems with civil +timekeeping that they +are <a href="https://www.bipm.org/en/cgpm-2022/resolution-4">planned +to be discontinued by 2035</a>, with some as-yet-undetermined +mechanism replacing them, perhaps after the year 2135. +Despite their impending obsolescence, a record of leap seconds is still +needed to resolve timestamps from 1972 through 2035. +</p> + <p> The <code><abbr>tz</abbr></code> code and data can account for leap seconds, thanks to code contributed by Bradley White. diff --git a/tz-link.html b/tz-link.html index d3b3766..608393f 100644 --- a/tz-link.html +++ b/tz-link.html @@ -1078,8 +1078,12 @@ leap second: its history and possible future</a>. <a href="https://www.ucolick.org/~sla/leapsecs/"><abbr>UTC</abbr> might be redefined without Leap Seconds</a> gives pointers on this -contentious issue, which was active until 2015 and could become active -again.</li> +contentious issue. +The General Conference on Weights and Measures +<a href="https://www.bipm.org/en/cgpm-2022/resolution-4">voted in 2022</a> +to discontinue the use of leap seconds by 2035, replacing them with an +as-yet-undetermined scheme some time after the year 2135. +</li> </ul> </section> -- 2.38.1

1 0

[PROPOSED] Use ‘restrict’ more consistently with standards
by Paul Eggert Dec. 20, 2022

Dec. 20, 2022

Previously, I assumed that if the declaration of a function F declared an argument via ‘T *restrict ARG’ then the compiler could take advantage of the ‘restrict’ when compiling F’s definition. However, apparently this is not the case: a top-level ‘restrict’ like that has no effect semantically unless it’s present in F’s definition. Fix this by using ‘restrict’ consistently in both declarations and definitions of functions where POSIX or the NetBSD API specifies ‘restrict’. (As an exception, do not use ‘restrict’ in tzfree’s argument as this appears to be a typo in NetBSD.) Do not bother using ‘restrict’ in internal functions, as this change is for consistency not for optimization. This change was prompted by a bug report for compiling on MS-Windows; see https://mm.icann.org/pipermail/tz/2022-December/032451.html Although the change does not fix the MS-Windows situation, the idea is to fix the MS-Windows issue another way. * asctime.c (asctime_r): * localtime.c (localtime_rz, localtime_r, gmtime_r, mktime_z): * private.h (asctime) [HAVE_INCOMPATIBLE_CTIME_R]: * strftime.c (strftime_l, strftime): Use ‘restrict’ consistently when POSIX or tzcode’s doc say so. --- NEWS | 4 ++++ asctime.c | 2 +- localtime.c | 9 +++++---- private.h | 2 +- strftime.c | 6 ++++-- 5 files changed, 15 insertions(+), 8 deletions(-) diff --git a/NEWS b/NEWS index 98cc14f..9b2d202 100644 --- a/NEWS +++ b/NEWS @@ -38,6 +38,10 @@ Unreleased, experimental changes '[[noreturn]] static void usage(void);' as strict C23 requires. (Problem reported by Houge Langley.) + The code's functions now constrain their arguments with the C + 'restrict' keyword consistently with their documentation. + This may allow future optimizations. + Release 2022g - 2022-11-29 08:58:31 -0800 diff --git a/asctime.c b/asctime.c index c84fe8c..375c913 100644 --- a/asctime.c +++ b/asctime.c @@ -61,7 +61,7 @@ static char buf_ctime[sizeof buf_asctime]; #endif char * -asctime_r(register const struct tm *timeptr, char *buf) +asctime_r(struct tm const *restrict timeptr, char *restrict buf) { static const char wday_name[][4] = { "Sun", "Mon", "Tue", "Wed", "Thu", "Fri", "Sat" diff --git a/localtime.c b/localtime.c index f1a8598..9b5d0a5 100644 --- a/localtime.c +++ b/localtime.c @@ -1628,7 +1628,8 @@ localsub(struct state const *sp, time_t const *timep, int_fast32_t setname, #if NETBSD_INSPIRED struct tm * -localtime_rz(struct state *sp, time_t const *timep, struct tm *tmp) +localtime_rz(struct state *restrict sp, time_t const *restrict timep, + struct tm *restrict tmp) { return localsub(sp, timep, 0, tmp); } @@ -1660,7 +1661,7 @@ localtime(const time_t *timep) } struct tm * -localtime_r(const time_t *timep, struct tm *tmp) +localtime_r(const time_t *restrict timep, struct tm *restrict tmp) { return localtime_tzset(timep, tmp, false); } @@ -1693,7 +1694,7 @@ gmtsub(ATTRIBUTE_MAYBE_UNUSED struct state const *sp, time_t const *timep, */ struct tm * -gmtime_r(const time_t *timep, struct tm *tmp) +gmtime_r(time_t const *restrict timep, struct tm *restrict tmp) { gmtcheck(); return gmtsub(gmtptr, timep, 0, tmp); @@ -2297,7 +2298,7 @@ mktime_tzname(struct state *sp, struct tm *tmp, bool setname) #if NETBSD_INSPIRED time_t -mktime_z(struct state *sp, struct tm *tmp) +mktime_z(struct state *restrict sp, struct tm *restrict tmp) { return mktime_tzname(sp, tmp, false); } diff --git a/private.h b/private.h index 7ddf4e5..5043cb8 100644 --- a/private.h +++ b/private.h @@ -920,7 +920,7 @@ static_assert(! TYPE_SIGNED(time_t) || ! SIGNED_PADDING_CHECK_NEEDED #if HAVE_INCOMPATIBLE_CTIME_R #undef asctime_r #undef ctime_r -char *asctime_r(struct tm const *, char *); +char *asctime_r(struct tm const *restrict, char *restrict); char *ctime_r(time_t const *, char *); #endif /* HAVE_INCOMPATIBLE_CTIME_R */ diff --git a/strftime.c b/strftime.c index b23b610..df16983 100644 --- a/strftime.c +++ b/strftime.c @@ -116,7 +116,8 @@ static char * _yconv(int, int, bool, bool, char *, char const *); #if HAVE_STRFTIME_L size_t -strftime_l(char *s, size_t maxsize, char const *format, struct tm const *t, +strftime_l(char *restrict s, size_t maxsize, char const *restrict format, + struct tm const *restrict t, ATTRIBUTE_MAYBE_UNUSED locale_t locale) { /* Just call strftime, as only the C locale is supported. */ @@ -125,7 +126,8 @@ strftime_l(char *s, size_t maxsize, char const *format, struct tm const *t, #endif size_t -strftime(char *s, size_t maxsize, const char *format, const struct tm *t) +strftime(char *restrict s, size_t maxsize, char const *restrict format, + struct tm const *restrict t) { char * p; int saved_errno = errno; -- 2.38.1

1 0

Confusing zdump output for America/Ojinaga
by Dave Rolsky Dec. 14, 2022

Dec. 14, 2022

I'm a bit confused regarding the output from zdump for the new America/Ojinaga zone. Here's the output for 2022: America/Ojinaga Sun Mar 13 08:59:59 2022 UT = Sun Mar 13 01:59:59 2022 MST isdst=0 gmtoff=-25200 America/Ojinaga Sun Mar 13 09:00:00 2022 UT = Sun Mar 13 03:00:00 2022 MDT isdst=1 gmtoff=-21600 America/Ojinaga Sun Oct 30 07:59:59 2022 UT = Sun Oct 30 01:59:59 2022 MDT isdst=1 gmtoff=-21600 America/Ojinaga Sun Oct 30 08:00:00 2022 UT = Sun Oct 30 03:00:00 2022 CDT isdst=1 gmtoff=-18000 America/Ojinaga Sun Nov 6 06:59:59 2022 UT = Sun Nov 6 01:59:59 2022 CDT isdst=1 gmtoff=-18000 America/Ojinaga Sun Nov 6 07:00:00 2022 UT = Sun Nov 6 01:00:00 2022 CST isdst=0 gmtoff=-21600 Note that there's no November 30 event. But based on the zone's definition I'd expect to see these events: Oct 30 - change to _CST_ Nov 30 - No change, I guess, since the change to the US rules on Nov 30 doesn't actually change the offset or isdst flag. But maybe I'm misunderstanding how to interpret the zone file definition? Cheers, Dave Rolsky http://blog.urth.org https://github.com/autarch

3 4

[PATCH v2 1/4] zic.8: Add public domain notice
by Alejandro Colomar Dec. 13, 2022

Dec. 13, 2022

Signed-off-by: Alejandro Colomar <alx(a)kernel.org> --- Hi Paul, v2: - This time I sent them to the tz mailing list too (and also linux-man@). - Added ACK and review from Branden in 3/4 and 4/4. - Added comment from Branden to commit message in 4/4. - Added tweak suggested by Branden in 3/4. zic.8 | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/zic.8 b/zic.8 index f79148f4..c2c61739 100644 --- a/zic.8 +++ b/zic.8 @@ -1,3 +1,7 @@ +.\" %%%LICENSE_START(PUBLIC_DOMAIN) +.\" This page is in the public domain +.\" %%%LICENSE_END +.\" .TH ZIC 8 .SH NAME zic \- timezone compiler -- 2.38.1

3 18