- tz - lists.iana.org

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

Single source of truth for timezone data
by Benjamin Drung Dec. 11, 2022

Dec. 11, 2022

Hi everyone, I am writing this mail with my distribution maintainer hat on since I am responsible for keeping the tzdata package up-to-date in Ubuntu. I like to propose to have a single source of truth for timezone data, which should be the tzdata source package. Updating this package in a distribution like Debian/Ubuntu should be enough to update all consumers in the distribution. Sadly this is currently not the case. Ubuntu since 20.04 (focal) adds the four icu source files metaZones.txt, timezoneTypes.txt, windowsZones.txt, and zoneinfo64.txt from https://github.com/unicode-org/icu-data to the tzdata source package. Then it uses genrb and icupkg to generate the .res files. Since the icu project lacks behind the tzdata release by hours up to days, Ubuntu has to update tzdata twice (first the tzdata release, then the icu update). metaZones.txt, timezoneTypes.txt, and windowsZones.txt are generated using tools/cldr/cldr-to-icu/build-icu-data.xml from https://github.com/unicode-org/icu. zoneinfo64.txt is generated by tz2icu. build-icu-data.xml uses https://github.com/unicode-org/cldr as input to convert the cldr data to icu. If I saw that correctly, only common/supplemental/metaZones.xml needs to be updated there on an update. Can tzdata include the necessary data and tools to generate metaZones.xml from its source? Then it would be possible to generate the icu data from the tzdata source without the need to wait for icu to catch up. Then Debian/Ubuntu can ship a tzdata-icu package for it [1]. [1] https://bugs.debian.org/954112 -- Benjamin Drung Debian & Ubuntu Developer

9 23

Error in America/Ojinaga
by Nikos (Nikolaos) Papadakos, PhD Dec. 10, 2022

Dec. 10, 2022

Hello, We are suspecting that your timezone update tzdb 2022g is incorrectly accounting for America/Ojinaga. Our customer is a major airline in Mexico and they tell me the time should America/Ojinaga should be the same as America/Denver. They provide as evidence official announcements in Spanish language. For example: https://www.dof.gob.mx/nota_detalle.php?codigo=5672650&fecha=29/11/2022#gsc… which says: "Artículo 5. III. Para el Estado de Baja California, así como para los municipios de Janos, Ascensión, Juárez, Praxedis G. Guerrero y Guadalupe, del Estado de Chihuahua, acorde a sus correlativos a su franja fronteriza, se aplica el meridiano 105 grados al oeste de Greenwich." I don't speak Spanish to be honest, my customer does. In the above the phrase seems to be "Juárez [...] del Estado de Chihuahua" which isreferring specifically to Ciudad Juárez in the State of Chihuahua. And then it says "el meridiano 105 grados al oeste de Greenwich" giving the degrees from Greenwich. They've given me some other references, but the above seems the most official. I would like to ask you to please double check which one is the correct. Best regards, Nikos P.S.: Please do not use my name or my company's name.

2 2