- tz - lists.iana.org

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

Re: [tz] Error in America/Ojinaga
by Brian Inglis Dec. 10, 2022

Dec. 10, 2022

On 2022-12-09 15:11, Tim Parenti via tz wrote: > On Fri, 9 Dec 2022 at 16:46, Nikos (Nikolaos) Papadakos, PhD wrote: >> Our customer is a major airline in Mexico and they tell me the time >> should America/Ojinaga should be the same as America/Denver. > It is our understanding that the recent changes split time zone observances > along Chihuahua's northern border. According to that split, from 2022-11-30, > Ojinaga is like America/Chicago, while Ciudad Juárez is like America/Denver. >> 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." > While the above describes that the municipio of Juárez (including its municipal > seat, Ciudad Juárez) observes a standard time of UTC-7, which is like > America/Denver, the section immediately prior reads: > II. Para los municipios de Coyame del Sotol, Ojinaga y Manuel Benavides, > del Estado de Chihuahua, acorde a sus correlativos a su franja fronteriza, > se aplica el meridiano 90 grados al oeste de Greenwich; > …meaning that the city and municipio of Ojinaga follow UTC-6, which is like > America/Chicago. > A new zone, America/Ciudad_Juarez, was split off from America/Ojinaga in 2022g > to allow for these differences in timekeeping. Since this zone did not exist > prior to 2022g, those in the western portions of Chihuahua's border region > (including Juárez) will need to switch to it, as the time in and around Juárez > and Chihuahua's northwest no longer matches the time in Ojinaga and Chihuahua's > northeast. Nor the time in Chihuahua's interior which is on CST like Ojinaga. The airline can check the IATA SSIM Schedule Time Zones for CUU/MMC Chihuahua and CJS/MMCS Ciudad Juarez to confirm the changes (Ojinaga has no airport). -- 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

Re: [tz] Single source of truth for timezone data
by Brian Inglis Dec. 9, 2022

Dec. 9, 2022

On 2022-12-08 13:50, Paul Eggert via tz wrote: > On 2022-12-08 05:24, Almaz Mingaleev wrote: >>>> new timezone abbreviation "XYT", downstream distros like Ubuntu can >>>> immediately ship the new P without waiting for i18n updates. P will >> It is not a problem if a distro ships it, it is a problem if this new >> stuff leaks to the external world. > Sorry, I'm not following. When Ubuntu ships a new tzdata package then surely > that has "leaked" to the outside world? >> It would be naive to expect from a user base of a service to have >> up-to-date time zone data even after a month after TZDB release. > In the past I've gotten my Ubuntu systems updated within 24 hours of a tzdata > release, simply by applying patches as usual from Ubuntu. But as Benjamin > indicates, this is not happening with 2022g. I just now checked for updates and > I'm still stuck on 2022f. So from my point of view, Ubuntu is slow in this case > - instead of taking less than a day, it's taking more than a week. >> being consistently wrong about _new_ changes is better >> than having different answers within the platform. > As a Ubuntu user, I'd prefer tzdata to be up-to-date even though ICU is > out-of-date, over having both tzdata and ICU out-of-date. Of course Ubuntu > differs from Android in that most apps use tzdata not ICU. Still, I'm a bit > curious what end-user-visible problems would occur on Android and/or Ubuntu if > tzdata leads ICU slightly. I know you've seen problems, but were they end-user > problems or just test-case problems? On Ubuntu various other copies of tzdata > (e.g., Python's) can be slightly out of date too, but this doesn't seem to be > much of an issue. >> It is not translations that we are waiting for, but changes like [1 >> <https://github.com/unicode-org/icu/pull/2261/files>]. Recent time zone >> changes were short notice ones and ICU team (thanks Yoshito and others!) >> did these changes very quickly. > Thanks, I didn't know that. > Here's a timeline I see for the latest Mexico change: > * 2022-11-28 17:00 UTC - news article published announcing the change (which is > not official yet, I think) > <http://puentelibre.mx/noticia/ciudad_juarez_cambio_horario_noviembre_2022/> > * 2022-11-29 03:55:31 UTC - tz mailing list notified > <https://mm.icann.org/pipermail/tz/2022-November/032365.html> > * 2022-11-29 17:42:29 UTC (14 hours after notification) - tzdb 2022g announced > <https://mm.icann.org/pipermail/tz-announce/2022-November/000076.html> > * 2022-11-29 18:23:41 UTC (less than an hour after tzdb 2022g announcement) > tzdata 2022g-r0 released for Alpine Linux > <https://pkgs.alpinelinux.org/package/edge/main/x86/tzdata> > * 2022-11-30 07:06 UTC (7 hours after tzdb 2022g announcement) - tzdata 2022g-1 > released for Arch Linux <https://archlinux.org/packages/core/x86_64/tzdata/> > * 2022-12-01 03:08:08 UTC (33 hours after tzdb 2022g announcement) - > abovementioned ICU patch committed > * 2022-12-01 12:38:06 UTC (9 hours after ICU patch committed) - Ubuntu patch > committed <https://launchpad.net/ubuntu/+source/tzdata/2022g-0ubuntu0.22.10.1> > * 2022-12-05 (4 days after ICU patch committed) - Red Hat Enterprise Linux fix > available to users <https://access.redhat.com/errata/RHBA-2022:8785> > * 2022-12-07 (6 days after ICU patch committed) - Android patch committed > <https://android.googlesource.com/platform/system/timezone/+/ea3e0ece71974c1…> > * now (a week after ICU patch committed) - my Ubuntu workstation is still not > updated. > We should be able to do better than this; that is, be more like Alpine or Arch > Linux, or at least more like RHEL (though I see that Fedora still hasn't > released 2022g...). Though ICU is part of the problem (as is tzdb itself :-), > most of the delay seems to be occurring even after ICU patches are applied. Launchpad shows Ubuntu 22.10 Proposed kinetic-proposed/main tzdata 2022g, also jammy- and focal-proposed, released Dec 1 when the maintainer started this thread. You could add the -proposed source to apt sources, and/or set apt preferences to only use it for tzdata, as the -proposed source seems to be first to get ICU updates in tzdata package release yyyyX-0ubuntu0.MM.mm.1; -updates and -security follow. -- 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

[PROPOSED] America/Yellowknife now links to America/Edmonton
by Paul Eggert Dec. 9, 2022

Dec. 9, 2022

(Thanks to Almaz Mingaleev.) * NEWS: Mention this. * backzone (America/Yellowknife): Move Zone here ... * northamerica: ... from here. * zone.tab, zone1970.tab: Remove America/Yellowknife. --- NEWS | 8 ++++++++ backzone | 5 +++++ northamerica | 7 ------- zone.tab | 3 +-- zone1970.tab | 3 +-- 5 files changed, 15 insertions(+), 11 deletions(-) diff --git a/NEWS b/NEWS index ac0b611a..98cc14f7 100644 --- a/NEWS +++ b/NEWS @@ -4,6 +4,7 @@ Unreleased, experimental changes Briefly: Much of Greenland still uses DST from 2024 on. + America/Yellowknife now links to America/Edmonton. The code now defaults to C99 or later. Fix use of C23 attributes. @@ -17,6 +18,13 @@ Unreleased, experimental changes This change from 2022g doesn't affect timestamps until 2024-03-30, and doesn't affect tm_isdst until 2023-03-25. + Changes to past timestamps + + America/Yellowknife has changed from a Zone to a backward + compatibility Link, as it no longer differs from America/Edmonton + since 1970. (Thanks to Almaz Mingaleev.) This affects some + pre-1948 timestamps. The old data are now in 'backzone'. + Changes to code The code by default is now designed for C99 or later. To build in diff --git a/backzone b/backzone index 7803c57d..1bd23ac6 100644 --- a/backzone +++ b/backzone @@ -928,6 +928,11 @@ Zone America/Thunder_Bay -5:57:00 - LMT 1895 Zone America/Tortola -4:18:28 - LMT 1911 Jul # Road Town -4:00 - AST +# Yellowknife, Northwest Territories +Zone America/Yellowknife 0 - -00 1935 # Yellowknife founded? + -7:00 NT_YK M%sT 1980 + -7:00 Canada M%sT + # Dumont d'Urville, Île des Pétrels, -6640+14001, since 1956-11 # <https://en.wikipedia.org/wiki/Dumont_d'Urville_Station> (2005-12-05) # diff --git a/northamerica b/northamerica index e33701bf..24b68e72 100644 --- a/northamerica +++ b/northamerica @@ -2125,10 +2125,6 @@ Zone America/Fort_Nelson -8:10:47 - LMT 1884 # Nunavut ... moved ... to incorporate the whole territory into one time zone. # Nunavut moves to single time zone Oct. 31 # http://www.nunatsiaq.com/nunavut/nvt90903_13.html -# -# From Antoine Leca (1999-09-06): -# We then need to create a new timezone for the Kitikmeot region of Nunavut -# to differentiate it from the Yellowknife region. # From Paul Eggert (1999-09-20): # Basic Facts: The New Territory @@ -2322,9 +2318,6 @@ Zone America/Cambridge_Bay 0 - -00 1920 # trading post est.? -5:00 - EST 2000 Nov 5 0:00 -6:00 - CST 2001 Apr 1 3:00 -7:00 Canada M%sT -Zone America/Yellowknife 0 - -00 1935 # Yellowknife founded? - -7:00 NT_YK M%sT 1980 - -7:00 Canada M%sT Zone America/Inuvik 0 - -00 1953 # Inuvik founded -8:00 NT_YK P%sT 1979 Apr lastSun 2:00 -7:00 NT_YK M%sT 1980 diff --git a/zone.tab b/zone.tab index 6e5adb9f..5d5c79ff 100644 --- a/zone.tab +++ b/zone.tab @@ -121,9 +121,8 @@ CA +744144-0944945 America/Resolute Central - NU (Resolute) CA +624900-0920459 America/Rankin_Inlet Central - NU (central) CA +5024-10439 America/Regina CST - SK (most areas) CA +5017-10750 America/Swift_Current CST - SK (midwest) -CA +5333-11328 America/Edmonton Mountain - AB; BC (E); SK (W) +CA +5333-11328 America/Edmonton Mountain - AB; BC (E); NT (E); SK (W) CA +690650-1050310 America/Cambridge_Bay Mountain - NU (west) -CA +6227-11421 America/Yellowknife Mountain - NT (central) CA +682059-1334300 America/Inuvik Mountain - NT (west) CA +4906-11631 America/Creston MST - BC (Creston) CA +5546-12014 America/Dawson_Creek MST - BC (Dawson Cr, Ft St John) diff --git a/zone1970.tab b/zone1970.tab index a9b36d36..819316be 100644 --- a/zone1970.tab +++ b/zone1970.tab @@ -108,9 +108,8 @@ CA +744144-0944945 America/Resolute Central - NU (Resolute) CA +624900-0920459 America/Rankin_Inlet Central - NU (central) CA +5024-10439 America/Regina CST - SK (most areas) CA +5017-10750 America/Swift_Current CST - SK (midwest) -CA +5333-11328 America/Edmonton Mountain - AB; BC (E); SK (W) +CA +5333-11328 America/Edmonton Mountain - AB; BC (E); NT (E); SK (W) CA +690650-1050310 America/Cambridge_Bay Mountain - NU (west) -CA +6227-11421 America/Yellowknife Mountain - NT (central) CA +682059-1334300 America/Inuvik Mountain - NT (west) CA +5546-12014 America/Dawson_Creek MST - BC (Dawson Cr, Ft St John) CA +5848-12242 America/Fort_Nelson MST - BC (Ft Nelson) -- 2.37.2

2 2

[PROPOSED] Try to check longstanding padding assumptions
by Paul Eggert Dec. 8, 2022

Dec. 8, 2022

This is helpful only when porting to oddball platforms in some situations where time_t is signed and has padding bits. (Even C23 allows these platforms.) Formerly tzcode would silently have undefined runtime behavior on such platforms; with this patch, there is likely a compile-time diagnostic instead. * private.h (static_assert): New macro, defined for pre-C23 compilers. (SIGNED_PADDING_CHECK_NEEDED): New constant. Try to check that TIME_T_MIN and TIME_T_MAX are actually the min and max time_t values. --- private.h | 19 ++++++++++++++++++- 1 file changed, 18 insertions(+), 1 deletion(-) diff --git a/private.h b/private.h index 1d6ddf7..7ddf4e5 100644 --- a/private.h +++ b/private.h @@ -43,6 +43,10 @@ # include <stdbool.h> #endif +#if __STDC_VERSION__ < 202311 +# define static_assert(cond) extern int static_assert_check[(cond) ? 1 : -1] +#endif + /* ** zdump has been made independent of the rest of the time ** conversion package to increase confidence in the verification it provides. @@ -833,10 +837,23 @@ ATTRIBUTE_REPRODUCIBLE time_t time2posix_z(timezone_t, time_t); int: INT_MAX, long: LONG_MAX, long long: LLONG_MAX, \ default: TIME_T_MAX_NO_PADDING) \ : (time_t) -1) +enum { SIGNED_PADDING_CHECK_NEEDED + = _Generic((time_t) 0, + signed char: false, short: false, + int: false, long: false, long long: false, + default: true) }; #else # define TIME_T_MIN TIME_T_MIN_NO_PADDING # define TIME_T_MAX TIME_T_MAX_NO_PADDING -#endif +enum { SIGNED_PADDING_CHECK_NEEDED = true }; +#endif +/* Try to check the padding assumptions. Although TIME_T_MAX and the + following check can both have undefined behavior on oddball + platforms due to shifts exceeding widths of signed integers, these + platforms' compilers are likely to diagnose these issues in integer + constant expressions, so it shouldn't hurt to check statically. */ +static_assert(! TYPE_SIGNED(time_t) || ! SIGNED_PADDING_CHECK_NEEDED + || TIME_T_MAX >> (TYPE_BIT(time_t) - 2) == 1); /* ** 302 / 1000 is log10(2.0) rounded up. -- 2.38.1

1 0

[PROPOSED] Update city lists in theory.html
by Paul Eggert Dec. 7, 2022

Dec. 7, 2022

* theory.html: Update xMT city lists to match what’s currently generated by the default build. --- theory.html | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/theory.html b/theory.html index 6a39ce7a..fbbb9e47 100644 --- a/theory.html +++ b/theory.html @@ -494,7 +494,7 @@ in decreasing order of importance: <p> <small>These abbreviations are: AMT Asunción, Athens; - BMT Baghdad, Bangkok, Batavia, Bermuda, Bern, Bogotá, Bridgetown, + BMT Baghdad, Bangkok, Batavia, Bermuda, Bern, Bogotá, Brussels, Bucharest; CMT Calamarca, Caracas, Chisinau, Colón, Córdoba; DMT Dublin/Dunsink; @@ -506,7 +506,7 @@ in decreasing order of importance: IMT Irkutsk, Istanbul; JMT Jerusalem; KMT Kaunas, Kyiv, Kingston; - LMT Lima, Lisbon, local, Luanda; + LMT Lima, Lisbon, local; MMT Macassar, Madras, Malé, Managua, Minsk, Monrovia, Montevideo, Moratuwa, Moscow; PLMT Phù Liễn; -- 2.37.2

1 0

[PATCH] Update abbreviation lists in theory.html
by Paul Eggert Dec. 7, 2022

Dec. 7, 2022

* theory.html: Update abbreviation lists to match what’s currently generated by the default build. --- theory.html | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/theory.html b/theory.html index f2b798be..6a39ce7a 100644 --- a/theory.html +++ b/theory.html @@ -443,11 +443,11 @@ in decreasing order of importance: CAT/CAST Central Africa, CET/CEST/CEMT Central European, ChST Chamorro, - CST/CDT/CWT/CPT/CDDT Central [North America], + CST/CDT/CWT/CPT Central [North America], CST/CDT China, GMT/BST/IST/BDST Greenwich, EAT East Africa, - EST/EDT/EWT/EPT/EDDT Eastern [North America], + EST/EDT/EWT/EPT Eastern [North America], EET/EEST Eastern European, GST/GDT Guam, HST/HDT/HWT/HPT Hawaii, @@ -460,13 +460,13 @@ in decreasing order of importance: MET/MEST Middle European (a backward-compatibility alias for Central European), MSK/MSD Moscow, - MST/MDT/MWT/MPT/MDDT Mountain, + MST/MDT/MWT/MPT Mountain, NST/NDT/NWT/NPT/NDDT Newfoundland, NST/NDT/NWT/NPT Nome, NZMT/NZST New Zealand through 1945, NZST/NZDT New Zealand 1946–present, PKT/PKST Pakistan, - PST/PDT/PWT/PPT/PDDT Pacific, + PST/PDT/PWT/PPT Pacific, PST/PDT Philippine, SAST South Africa, SST Samoa, @@ -512,6 +512,7 @@ in decreasing order of importance: PLMT Phù Liễn; PMT Paramaribo, Paris, Perm, Pontianak, Prague; PMMT Port Moresby; + PPMT Port-au-Prince; QMT Quito; RMT Rangoon, Riga, Rome; SDMT Santo Domingo; @@ -519,8 +520,7 @@ in decreasing order of importance: SMT Santiago, Simferopol, Singapore, Stanley; TBMT Tbilisi; TMT Tallinn, Tehran; - WMT Warsaw; - ZMT Zomba.</small> + WMT Warsaw.</small> </p> <p> -- 2.37.2

1 0

Re: [tz] TZDB patches, UTF-8, and Microsoft Exchange
by Brian Inglis Dec. 4, 2022

Dec. 4, 2022

On 2022-12-04 12:48, Fred Gleason via tz wrote: > On Dec 2, 2022, at 17:21, Derick Rethans via tz <tz(a)iana.org > <mailto:tz@iana.org>> wrote: > >> This problem would go away if you'd except change requests through GitHub's >> pull request feature. > > I for one heartily second this suggestion. While I understand that this can be a > sensitive issue for some long-time contributors here, given the composition of > TZDB’s audience (veteran coders plus the occasional technically > non-sophisticated user), I think anything that simplifies the overall workflow > while making the process more transparent to non-coders would be a net win. > > >> It's quite a common and modern method to propose changes to open source >> software, that I'd expect many would already be familiar with. > > I agree. The GitHub pull request process has become a sort of _lingua franca_ in > the code development realm, arguably more so than any other single methodology > for managing distributed open source development. In that context, the current > _status quo_ is rather *anti*-user friendly in the sense that many coders, when > first encountering the TZDB GitHub repo think that they already know how to > generate and submit patches; only later discovering that they in fact don’t, > since what is arguably the central workflow metaphor of what makes GitHub useful > has (seemingly inexplicably) been switched off. > > On the basis of the patches I’ve seen go by on this listserv over the past few > years, it would also seem that “easing/reducing maintenance burden” has become a > major goal for TZDB. Given that, I would respectfully argue that moving to a > PR-based workflow would do more towards that end than any number of minor code > polishing changes. > > > On Dec 2, 2022, at 17:43, Paul Eggert via tz <tz(a)iana.org <mailto:tz@iana.org>> > wrote: > >> Yes, but GitHub has its own problems. I'd rather stick with email, just as >> many other projects use email for this sort of thing. > > Well, this one at least does. FWIW, none of the other FOSS projects whose dev > lists I follow use the traditional patches-via-email workflow any more. While by > no means all of them use GitHub, what they all do use is some sort of system > that provides automated patch generation/testing/merging along with a GUI option > that allows non-coder types some level of visibility into the process. > > >> Also, I've been thinking of moving the development repository off GitHub for >> other reasons, and I don't want to rely on GitHub-specific features. > > Would you care to share with us what some of those “other reasons” might be? At a guess, I'd imagine for a multi-GNU project contributor, even using a proprietary vendor locked-in (and potentially future deprecated or locked-out) platform might be an issue (possibly queried only in person or private DM), as it is for many other open source contributors, where even mentioning GitHub evokes a spit-blah *NEVER* response, and moving to GH would result in losing some contributions. For some open-source projects, GH is used only as a public and backup repo for their primary dev workflows, as are sv.gnu.org and sv.non-gnu.org in some cases. A number are using in-house and/or public GitLab instances, and others have surfaced their email with public-inbox like https://lore.kernel.org/ where issues and patches can be handled using workflow tools like https://git.kernel.org/pub/scm/utils/b4/b4.git It would be good if the IETF, IANA, and/or ICANN made their email available in such searchable archives, an area where tz is currently lacking. -- 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

[PATCH] Fix America/Nuuk timezone change
by Thomas M. Steenholdt Dec. 4, 2022

Dec. 4, 2022

Fix the upcoming move of America/Nuuk from normaltime -03 to -02, according to the passed bill. --- europe | 19 +++++++++++++++++-- 1 file changed, 17 insertions(+), 2 deletions(-) diff --git a/europe b/europe index a3547b4f..71ea3ab2 100644 --- a/europe +++ b/europe @@ -1126,6 +1126,21 @@ Zone Atlantic/Faroe -0:27:04 - LMT 1908 Jan 11 # Tórshavn # "bekymringer" URL says the intent is no transition March 25, that # Greenland will not go back to winter time in fall 2023, and that # only America/Nuuk is affected (though further changes may occur). +# +# From Thomas M. Steenholdt (2022-12-02): +# Processing of the bill is documented here: +# https://ina.gl/samlinger/oversigt-over-samlinger/samling/dagsordener/dagsor… +# Notably: +# - The bill to move America/Nuuk from UTC-03 to UTC-02 passed. +# - The bill to stop observing DST did not (Greenland will stop observing DST +# when EU does). +# Details on the implementation are here (section 6): +# https://ina.gl/dvd/EM%202022/pdf/media/2553529/pkt17_em2022_tidens_bestemme… +# This is how the change will be implemented: +# 1. The shift *to* DST in 2023 happens as normal. +# 2. The shift *from* DST in 2023 happens as normal, but coincides with the +# shift to UTC-02 normaltime (people will not change their clocks here). +# 3. After this, DST is still observed, but as -02/-01 instead of -03/-02. # Rule NAME FROM TO - IN ON AT SAVE LETTER/S Rule Thule 1991 1992 - Mar lastSun 2:00 1:00 D @@ -1149,8 +1164,8 @@ Zone America/Scoresbysund -1:27:52 - LMT 1916 Jul 28 # Ittoqqortoormiit -1:00 EU -01/+00 Zone America/Nuuk -3:26:56 - LMT 1916 Jul 28 # Godthåb -3:00 - -03 1980 Apr 6 2:00 - -3:00 EU -03/-02 2023 Mar 25 22:00 - -2:00 - -02 + -3:00 EU -03/-02 2023 Oct 28 23:00 + -2:00 EU -02/-01 Zone America/Thule -4:35:08 - LMT 1916 Jul 28 # Pituffik -4:00 Thule A%sT -- 2.34.1

5 7

[PROPOSED] Default to assuming C99 or later
by Paul Eggert Dec. 2, 2022

Dec. 2, 2022

By default, assume the compiler and library support C99 or later. Continue to port to C89 platforms only if the new macro PORT_TO_C89 is nonzero. This new macro is a transitional aid, and is planned to be removed in a future version that always assumes C99 or later. * Makefile, NEWS: Mention this. * private.h (PORT_TO_C89): New macro. (SUPPORT_C89): Move up. (true, false, bool) [!PORT_TO_C89]: Assume C99 or later. If !PORT_TO_C89 simply include <inttypes.h> rather than fooling around with conditional stdint.h, conditional inttypes.h, and lots of other conditional definitions. (restrict) [!PORT_TO_C89]: Do not define. * zdump.c (HAVE_SNPRINTF) [!PORT_TO_C89]: Now true. --- Makefile | 14 ++++++++------ NEWS | 11 ++++++----- private.h | 35 +++++++++++++++++++++++++---------- zdump.c | 2 +- 4 files changed, 40 insertions(+), 22 deletions(-) diff --git a/Makefile b/Makefile index 63f3b5ca..8bee50d8 100644 --- a/Makefile +++ b/Makefile @@ -220,7 +220,7 @@ LDLIBS= # -DHAVE_INCOMPATIBLE_CTIME_R if your system's time.h declares # ctime_r and asctime_r incompatibly with the POSIX standard # (Solaris when _POSIX_PTHREAD_SEMANTICS is not defined). -# -DHAVE_INTTYPES_H=0 if <inttypes.h> does not work* +# -DHAVE_INTTYPES_H=0 if <inttypes.h> does not work*+ # -DHAVE_LINK=0 if your system lacks a link function # -DHAVE_LOCALTIME_R=0 if your system lacks a localtime_r function # -DHAVE_LOCALTIME_RZ=0 if you do not want zdump to use localtime_rz @@ -229,24 +229,24 @@ LDLIBS= # -DHAVE_POSIX_DECLS=0 if your system's include files do not declare # functions like 'link' or variables like 'tzname' required by POSIX # -DHAVE_SETENV=0 if your system lacks the setenv function -# -DHAVE_SNPRINTF=0 if your system lacks the snprintf function +# -DHAVE_SNPRINTF=0 if your system lacks the snprintf function+ # -DHAVE_STDCKDINT_H=0 if neither <stdckdint.h> nor substitutes like # __builtin_add_overflow work* -# -DHAVE_STDINT_H=0 if <stdint.h> does not work* +# -DHAVE_STDINT_H=0 if <stdint.h> does not work*+ # -DHAVE_STRFTIME_L if <time.h> declares locale_t and strftime_l # -DHAVE_STRDUP=0 if your system lacks the strdup function -# -DHAVE_STRTOLL=0 if your system lacks the strtoll function +# -DHAVE_STRTOLL=0 if your system lacks the strtoll function+ # -DHAVE_SYMLINK=0 if your system lacks the symlink function # -DHAVE_SYS_STAT_H=0 if <sys/stat.h> does not work* # -DHAVE_TZSET=0 if your system lacks a tzset function # -DHAVE_UNISTD_H=0 if <unistd.h> does not work* # -DHAVE_UTMPX_H=0 if <utmpx.h> does not work* # -Dlocale_t=XXX if your system uses XXX instead of locale_t +# -DPORT_TO_C89 if tzcode should also run on C89 platforms+ # -DRESERVE_STD_EXT_IDS if your platform reserves standard identifiers # with external linkage, e.g., applications cannot define 'localtime'. # -Dssize_t=long on hosts like MS-Windows that lack ssize_t -# -DSUPPORT_C89 if you build or run tzcode on a C89 platform; this option -# is obsolescent and is planned to be removed when C99+ is required. +# -DSUPPORT_C89 if the tzcode library should support C89 callers+ # -DSUPPRESS_TZDIR to not prepend TZDIR to file names; this has # security implications and is not recommended for general use # -DTHREAD_SAFE to make localtime.c thread-safe, as POSIX requires; @@ -275,6 +275,8 @@ LDLIBS= # $(GCC_DEBUG_FLAGS) if you are using recent GCC and want lots of checking # # * Options marked "*" can be omitted if your compiler is C23 compatible. +# * Options marked "+" are obsolescent and are planned to be removed +# once the code assumes C99 or later. # # Select instrumentation via "make GCC_INSTRUMENT='whatever'". GCC_INSTRUMENT = \ diff --git a/NEWS b/NEWS index 25dcc875..91ec5056 100644 --- a/NEWS +++ b/NEWS @@ -3,15 +3,16 @@ News for the tz database Unreleased, experimental changes Briefly: - tzcode no longer supports C89 unless built with -DSUPPORT_C89 + The code now defaults to C99 or later. Fix use of C23 attributes. Changes to code - tzcode no longer supports C89 by default. To build or run in a - C89 environment, compile with -DSUPPORT_C89, a transitional aid - that is planned to be removed in a near-future version, when C99 - or later will be required. + The code by default is now designed for C99 or later. To build in + a C89 environment, compile with -DPORT_TO_C89. To support C89 + callers of the tzcode library, compile with -DSUPPORT_C89. The + two new macros are transitional aids planned to be removed in a + future version, when C99 or later will be required. On C23-compatible platforms tzcode no longer uses syntax like 'static [[noreturn]] void usage(void);'. Instead, it uses diff --git a/private.h b/private.h index 999c1648..1d6ddf73 100644 --- a/private.h +++ b/private.h @@ -17,12 +17,25 @@ ** Thank you! */ +/* PORT_TO_C89 means the code should work even if the underlying + compiler and library support only C89. SUPPORT_C89 means the + tzcode library should support C89 callers in addition to the usual + support for C99-and-later callers. These macros are obsolescent, + and the plan is to remove them along with any code needed only when + they are nonzero. */ +#ifndef PORT_TO_C89 +# define PORT_TO_C89 0 +#endif +#ifndef SUPPORT_C89 +# define SUPPORT_C89 0 +#endif + #ifndef __STDC_VERSION__ # define __STDC_VERSION__ 0 #endif /* Define true, false and bool if they don't work out of the box. */ -#if __STDC_VERSION__ < 199901 +#if PORT_TO_C89 && __STDC_VERSION__ < 199901 # define true 1 # define false 0 # define bool int @@ -100,10 +113,6 @@ # define HAVE_STRDUP 1 #endif -#ifndef HAVE_STRTOLL -# define HAVE_STRTOLL 1 -#endif - #ifndef HAVE_SYMLINK # define HAVE_SYMLINK 1 #endif /* !defined HAVE_SYMLINK */ @@ -185,6 +194,9 @@ #include <stddef.h> #include <string.h> +#if !PORT_TO_C89 +# include <inttypes.h> +#endif #include <limits.h> /* for CHAR_BIT et al. */ #include <stdlib.h> @@ -254,6 +266,8 @@ # define R_OK 4 #endif /* !defined R_OK */ +#if PORT_TO_C89 + /* ** Define HAVE_STDINT_H's default value here, rather than at the ** start, since __GLIBC__ and INTMAX_MAX's values depend on @@ -334,6 +348,9 @@ typedef int int_fast32_t; #ifndef INTMAX_MAX # ifdef LLONG_MAX typedef long long intmax_t; +# ifndef HAVE_STRTOLL +# define HAVE_STRTOLL true +# endif # if HAVE_STRTOLL # define strtoimax strtoll # endif @@ -396,6 +413,8 @@ typedef unsigned long uintmax_t; # define SIZE_MAX ((size_t) -1) #endif +#endif /* PORT_TO_C89 */ + /* Support ckd_add, ckd_sub, ckd_mul on C23 or recent-enough GCC-like hosts, unless compiled with -DHAVE_STDCKDINT_H=0 or with pre-C23 EDG. */ #if !defined HAVE_STDCKDINT_H && defined __has_include @@ -520,7 +539,7 @@ typedef unsigned long uintmax_t; # endif #endif -#if __STDC_VERSION__ < 199901 && !defined restrict +#if PORT_TO_C89 && __STDC_VERSION__ < 199901 && !defined restrict # define restrict /* empty */ #endif @@ -704,10 +723,6 @@ extern int daylight; extern long altzone; #endif -#ifndef SUPPORT_C89 -# define SUPPORT_C89 0 -#endif - /* ** The STD_INSPIRED functions are similar, but most also need ** declarations if time_tz is defined. diff --git a/zdump.c b/zdump.c index bac4a67a..5173c9ac 100644 --- a/zdump.c +++ b/zdump.c @@ -15,7 +15,7 @@ #include <stdio.h> #ifndef HAVE_SNPRINTF -# define HAVE_SNPRINTF (199901 <= __STDC_VERSION__) +# define HAVE_SNPRINTF (!PORT_TO_C89 || 199901 <= __STDC_VERSION__) #endif #ifndef HAVE_LOCALTIME_R -- 2.37.2

1 0

[PROPOSED] Port alignof to Oracle Developer Studio
by Paul Eggert Dec. 2, 2022

Dec. 2, 2022

* zic.c (alignof): Don’t include <stdalign.h> when compiling with Oracle Developer Studio, as release 12.6 lacks <stdalign.h> even though it #defines __STDC_VERSION__ to 201112L. Most likely this circa-2017 release, which #defines __SUNPRO_C to be 0x5150, is the last release, so assume that all releases lack <stdalign.h>. --- zic.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/zic.c b/zic.c index f143fcef..5612805f 100644 --- a/zic.c +++ b/zic.c @@ -67,7 +67,7 @@ enum { FORMAT_LEN_GROWTH_BOUND = 5 }; #endif /* The minimum alignment of a type, for pre-C23 platforms. */ -#if __STDC_VERSION__ < 201112 +#if __STDC_VERSION__ < 201112 || defined __SUNPRO_C # define alignof(type) offsetof(struct { char a; type b; }, b) #elif __STDC_VERSION__ < 202311 # include <stdalign.h> -- 2.37.2

2 2

1981/2 Singapore+Malaysia switch from GMT+0730 to GMT+0800
by Robert Elz Dec. 1, 2022

Dec. 1, 2022

This press release was discovered, and brought up in another forum by Geoff Clare. It conflicts with the data in the Asia/Singapore and Asia/Kuala-Lumpur zones. https://corporate.nas.gov.sg/media/collections-and-research/time-zone-adjus… That puts the change as being from 23:29:59 Dec 31, 1981 -> 00:00:00 Jan 1, 1982 whereas tzdata (going back to quite ancient versions) has the transition 23:59:59 Dec 31, 1981 -> 00:30:00 Jan 1, 1982 The version from the web page makes more sense to me (as in that is how I would have done that transition) but that does not mean that it is necessarily correct. Nothing there shows a copy of the actual gazette notification by the President (of Singapore in that case, but I think we can safely assume that it was done the same as in Malaysia) which would be the actual specification, but that 2015 press release says it happened as described that it would happen in the 1981 press release which is included there. The "asia" file just says of this transition: 7:30 - +0730 1982 Jan 1 8:00 - +08 which is correct in a sense for either version of when the transition occurred, and perhaps raises a general question of when a step forward takes place at the boundary between two days, does it more often delete the last part of the previous day or the first part of the next? I can find nothing in my tz list archives that says anything at all about this transition - the earliest message with any specific content about Singapore I could see was a Jan 2004 message from Mok Ly Yng (forwarded to the list by ado@), but that's really about earlier transitions - this one was already in the data (just with SGT instead of +0730 and +08). There's also a long Sept 2014 discussion about a zdump bug that this particular transition, as defined by zic, revealed, and a shorter discussion about the SGT removal in Sept 2018 - but that's all I managed to find about Singapore. While not about the Singapore/Malaysia zones themselves, even older data that appears on the list (ie: looking at diffs patches, and updated zone files) shows that in 1996 this transition was believed to have happened in May 1982 (which seems to be from Shanks). That altered in Dec 2003, in a change described as: * Fix several Malaysia and Singapore entries before 1983. Among other things, they enjoyed 20-minute DST from 1933 to 1936, and we have more-accurate dates for WWII transitions. (Thanks to Mok Ly Yng for this info.) which notably does not mention the change moving from May 1982 -> 1 Jan 1982 but that change was made in that version. Nothing appears to have happened since. I suspect it would be correct to change the first of those lines to be 7:30 - +0730 23:30 1981 Dec 30 but I am no authority on that. kre

5 13

[PROPOSED] Fix C23-related conformance bug
by Paul Eggert Dec. 1, 2022

Dec. 1, 2022

Problem reported by Houge Langley for ‘gcc -std=gnu99’ in: https://bugs.gentoo.org/show_bug.cgi?id=883719 * NEWS: Mention this. * date.c, localtime.c, private.h, zdump.c, zic.c: Use ATTRIBUTE_* at the start of function declarations, not later (such as after the keyword ‘static’). This is required for strict conformance to C23. --- NEWS | 6 ++++++ date.c | 2 +- localtime.c | 4 ++-- private.h | 6 +++--- zdump.c | 12 ++++++------ zic.c | 34 +++++++++++++++++----------------- 6 files changed, 35 insertions(+), 29 deletions(-) diff --git a/NEWS b/NEWS index 9cb175e7..25dcc875 100644 --- a/NEWS +++ b/NEWS @@ -4,6 +4,7 @@ Unreleased, experimental changes Briefly: tzcode no longer supports C89 unless built with -DSUPPORT_C89 + Fix use of C23 attributes. Changes to code @@ -12,6 +13,11 @@ Unreleased, experimental changes that is planned to be removed in a near-future version, when C99 or later will be required. + On C23-compatible platforms tzcode no longer uses syntax like + 'static [[noreturn]] void usage(void);'. Instead, it uses + '[[noreturn]] static void usage(void);' as strict C23 requires. + (Problem reported by Houge Langley.) + Release 2022g - 2022-11-29 08:58:31 -0800 diff --git a/date.c b/date.c index 11c5e5fe..97df6ab0 100644 --- a/date.c +++ b/date.c @@ -42,7 +42,7 @@ static void display(const char *, time_t); static void dogmt(void); static void errensure(void); static void timeout(FILE *, const char *, const struct tm *); -static ATTRIBUTE_NORETURN void usage(void); +ATTRIBUTE_NORETURN static void usage(void); int main(const int argc, char *argv[]) diff --git a/localtime.c b/localtime.c index f8a0a6eb..f1a8598b 100644 --- a/localtime.c +++ b/localtime.c @@ -843,7 +843,7 @@ is_digit(char c) ** Return a pointer to that character. */ -static ATTRIBUTE_REPRODUCIBLE const char * +ATTRIBUTE_REPRODUCIBLE static const char * getzname(register const char *strp) { register char c; @@ -864,7 +864,7 @@ getzname(register const char *strp) ** We don't do any checking here; checking is done later in common-case code. */ -static ATTRIBUTE_REPRODUCIBLE const char * +ATTRIBUTE_REPRODUCIBLE static const char * getqzname(register const char *strp, const int delim) { register int c; diff --git a/private.h b/private.h index c22354ac..999c1648 100644 --- a/private.h +++ b/private.h @@ -646,7 +646,7 @@ DEPRECATED_IN_C23 char *asctime(struct tm const *); char *asctime_r(struct tm const *restrict, char *restrict); DEPRECATED_IN_C23 char *ctime(time_t const *); char *ctime_r(time_t const *, char *); -double difftime(time_t, time_t) ATTRIBUTE_UNSEQUENCED; +ATTRIBUTE_UNSEQUENCED double difftime(time_t, time_t); size_t strftime(char *restrict, size_t, char const *restrict, struct tm const *restrict); # if HAVE_STRFTIME_L @@ -765,10 +765,10 @@ timezone_t tzalloc(char const *); void tzfree(timezone_t); # if STD_INSPIRED # if TZ_TIME_T || !defined posix2time_z -time_t posix2time_z(timezone_t, time_t) ATTRIBUTE_REPRODUCIBLE; +ATTRIBUTE_REPRODUCIBLE time_t posix2time_z(timezone_t, time_t); # endif # if TZ_TIME_T || !defined time2posix_z -time_t time2posix_z(timezone_t, time_t) ATTRIBUTE_REPRODUCIBLE; +ATTRIBUTE_REPRODUCIBLE time_t time2posix_z(timezone_t, time_t); # endif # endif #endif diff --git a/zdump.c b/zdump.c index 04953dcf..bac4a67a 100644 --- a/zdump.c +++ b/zdump.c @@ -89,7 +89,7 @@ static bool warned; static bool errout; static char const *abbr(struct tm const *); -static intmax_t delta(struct tm *, struct tm *) ATTRIBUTE_REPRODUCIBLE; +ATTRIBUTE_REPRODUCIBLE static intmax_t delta(struct tm *, struct tm *); static void dumptime(struct tm const *); static time_t hunt(timezone_t, time_t, time_t, bool); static void show(timezone_t, char *, time_t, bool); @@ -97,7 +97,7 @@ static void showextrema(timezone_t, char *, time_t, struct tm *, time_t); static void showtrans(char const *, struct tm const *, time_t, char const *, char const *); static const char *tformat(void); -static time_t yeartot(intmax_t) ATTRIBUTE_REPRODUCIBLE; +ATTRIBUTE_REPRODUCIBLE static time_t yeartot(intmax_t); /* Is C an ASCII digit? */ static bool @@ -125,7 +125,7 @@ is_alpha(char a) } } -static ATTRIBUTE_NORETURN void +ATTRIBUTE_NORETURN static void size_overflow(void) { fprintf(stderr, _("%s: size overflow\n"), progname); @@ -134,7 +134,7 @@ size_overflow(void) /* Return A + B, exiting if the result would overflow either ptrdiff_t or size_t. */ -static ATTRIBUTE_REPRODUCIBLE ptrdiff_t +ATTRIBUTE_REPRODUCIBLE static ptrdiff_t sumsize(size_t a, size_t b) { #ifdef ckd_add @@ -151,7 +151,7 @@ sumsize(size_t a, size_t b) /* Return a pointer to a newly allocated buffer of size SIZE, exiting on failure. SIZE should be nonzero. */ -static void * ATTRIBUTE_MALLOC +ATTRIBUTE_MALLOC static void * xmalloc(size_t size) { void *p = malloc(size); @@ -916,7 +916,7 @@ showextrema(timezone_t tz, char *zone, time_t lo, struct tm *lotmp, time_t hi) # include <stdarg.h> /* A substitute for snprintf that is good enough for zdump. */ -static int ATTRIBUTE_FORMAT((printf, 3, 4)) +ATTRIBUTE_FORMAT((printf, 3, 4)) static int my_snprintf(char *s, size_t size, char const *format, ...) { int n; diff --git a/zic.c b/zic.c index 892414af..f143fcef 100644 --- a/zic.c +++ b/zic.c @@ -459,20 +459,20 @@ static char roll[TZ_MAX_LEAPS]; ** Memory allocation. */ -static ATTRIBUTE_NORETURN void +ATTRIBUTE_NORETURN static void memory_exhausted(const char *msg) { fprintf(stderr, _("%s: Memory exhausted: %s\n"), progname, msg); exit(EXIT_FAILURE); } -static ATTRIBUTE_NORETURN void +ATTRIBUTE_NORETURN static void size_overflow(void) { memory_exhausted(_("size overflow")); } -static ATTRIBUTE_REPRODUCIBLE ptrdiff_t +ATTRIBUTE_REPRODUCIBLE static ptrdiff_t size_sum(size_t a, size_t b) { #ifdef ckd_add @@ -487,7 +487,7 @@ size_sum(size_t a, size_t b) size_overflow(); } -static ATTRIBUTE_REPRODUCIBLE ptrdiff_t +ATTRIBUTE_REPRODUCIBLE static ptrdiff_t size_product(ptrdiff_t nitems, ptrdiff_t itemsize) { #ifdef ckd_mul @@ -502,7 +502,7 @@ size_product(ptrdiff_t nitems, ptrdiff_t itemsize) size_overflow(); } -static ATTRIBUTE_REPRODUCIBLE ptrdiff_t +ATTRIBUTE_REPRODUCIBLE static ptrdiff_t align_to(ptrdiff_t size, ptrdiff_t alignment) { ptrdiff_t lo_bits = alignment - 1, sum = size_sum(size, lo_bits); @@ -526,7 +526,7 @@ memcheck(void *ptr) return ptr; } -static void * ATTRIBUTE_MALLOC +ATTRIBUTE_MALLOC static void * emalloc(size_t size) { return memcheck(malloc(size)); @@ -538,7 +538,7 @@ erealloc(void *ptr, size_t size) return memcheck(realloc(ptr, size)); } -static char * ATTRIBUTE_MALLOC +ATTRIBUTE_MALLOC static char * estrdup(char const *str) { return memcheck(strdup(str)); @@ -608,7 +608,7 @@ eat(int fnum, lineno num) eats(fnum, num, 0, -1); } -static void ATTRIBUTE_FORMAT((printf, 1, 0)) +ATTRIBUTE_FORMAT((printf, 1, 0)) static void verror(const char *const string, va_list args) { /* @@ -626,7 +626,7 @@ verror(const char *const string, va_list args) fprintf(stderr, "\n"); } -static void ATTRIBUTE_FORMAT((printf, 1, 2)) +ATTRIBUTE_FORMAT((printf, 1, 2)) static void error(const char *const string, ...) { va_list args; @@ -636,7 +636,7 @@ error(const char *const string, ...) errors = true; } -static void ATTRIBUTE_FORMAT((printf, 1, 2)) +ATTRIBUTE_FORMAT((printf, 1, 2)) static void warning(const char *const string, ...) { va_list args; @@ -666,7 +666,7 @@ close_file(FILE *stream, char const *dir, char const *name, } } -static ATTRIBUTE_NORETURN void +ATTRIBUTE_NORETURN static void usage(FILE *stream, int status) { fprintf(stream, @@ -3597,7 +3597,7 @@ lowerit(char a) } /* case-insensitive equality */ -static ATTRIBUTE_REPRODUCIBLE bool +ATTRIBUTE_REPRODUCIBLE static bool ciequal(register const char *ap, register const char *bp) { while (lowerit(*ap) == lowerit(*bp++)) @@ -3606,7 +3606,7 @@ ciequal(register const char *ap, register const char *bp) return false; } -static ATTRIBUTE_REPRODUCIBLE bool +ATTRIBUTE_REPRODUCIBLE static bool itsabbr(register const char *abbr, register const char *word) { if (lowerit(*abbr) != lowerit(*word)) @@ -3622,7 +3622,7 @@ itsabbr(register const char *abbr, register const char *word) /* Return true if ABBR is an initial prefix of WORD, ignoring ASCII case. */ -static ATTRIBUTE_REPRODUCIBLE bool +ATTRIBUTE_REPRODUCIBLE static bool ciprefix(char const *abbr, char const *word) { do @@ -3725,14 +3725,14 @@ getfields(char *cp, char **array, int arrayelts) return nsubs; } -static ATTRIBUTE_NORETURN void +ATTRIBUTE_NORETURN static void time_overflow(void) { error(_("time overflow")); exit(EXIT_FAILURE); } -static ATTRIBUTE_REPRODUCIBLE zic_t +ATTRIBUTE_REPRODUCIBLE static zic_t oadd(zic_t t1, zic_t t2) { #ifdef ckd_add @@ -3746,7 +3746,7 @@ oadd(zic_t t1, zic_t t2) time_overflow(); } -static ATTRIBUTE_REPRODUCIBLE zic_t +ATTRIBUTE_REPRODUCIBLE static zic_t tadd(zic_t t1, zic_t t2) { #ifdef ckd_add -- 2.37.2

2 1

[PROPOSED] Simplify zdump average-taking
by Paul Eggert Dec. 1, 2022

Dec. 1, 2022

* zdump.c (hunt): Simplify slightly, so that one more instruction can be int width rather than time_t width if that’s what the compiler prefers. No need to mention C89 in the comment, as C89 support is going away soon. (The code still happens to work in C89, for what it’s worth.) --- zdump.c | 10 +++------- 1 file changed, 3 insertions(+), 7 deletions(-) diff --git a/zdump.c b/zdump.c index a020102..04953dc 100644 --- a/zdump.c +++ b/zdump.c @@ -732,13 +732,9 @@ hunt(timezone_t tz, time_t lot, time_t hit, bool only_ok) for ( ; ; ) { /* T = average of LOT and HIT, rounding down. - Avoid overflow, even on oddball C89 platforms - where / rounds down and TIME_T_MIN == -TIME_T_MAX - so lot / 2 + hit / 2 might overflow. */ - time_t t = (lot / 2 - - ((lot % 2 + hit % 2) < 0) - + ((lot % 2 + hit % 2) == 2) - + hit / 2); + Avoid overflow. */ + int rem_sum = lot % 2 + hit % 2; + time_t t = (rem_sum == 2) - (rem_sum < 0) + lot / 2 + hit / 2; if (t == lot) break; tm_ok = my_localtime_rz(tz, &t, &tm) != NULL; -- 2.38.1

3 5

Re: [tz] New change in Mexico
by Brian Inglis Nov. 30, 2022

Nov. 30, 2022

On 2022-11-29 22:37, Tim Parenti wrote: > On Tue, 29 Nov 2022 at 13:29, Paul Eggert wrote: > I expect I didn't recognize > that as including Ciudad Juárez as opposed to one of the plain Juárezes > which also exist in Mexico. > On Tue, 29 Nov 2022 at 19:50, Heitor David Pinto wrote: > The municipalities have well-defined boundaries, see this map: > https://cuentame.inegi.org.mx/mapas/pdf/entidades/div_municipal/chihmpios.p… > Ah, that seems to be part of the issue — while the word "municipality" is often > used to refer to an individual settlement in US English, a "municipio" in Mexico > (and similar words in many other countries) is a second-level administrative > division, which is more akin to, say, a county in much of the US or a civil > parish in much of Britain. That is, these lists are not of individual > settlements which are far apart (although they often share names with such), but > rather of well-defined regions — administrative subdivisions of states — which, > as Heitor points out, cover the entire border. > https://en.wikipedia.org/wiki/Municipio <https://en.wikipedia.org/wiki/Municipio> > https://en.wikipedia.org/wiki/Municipalities_of_Mexico > <https://en.wikipedia.org/wiki/Municipalities_of_Mexico> > While "municipio" does, admittedly, seem to be best translated to English as > "municipality", since the English word has many meanings, it's maybe best to be > more faithful to the original Spanish use here for clarity. We've left > "municipio" untranslated in nearby commentary for Mexico before, so I've applied > the attached to the development repository to hopefully alleviate some further > confusion for others who might come to these comments unaware of some of the > details of Mexico's political subdivisions. While I don't necessarily expect > many more one-off adjustments to the new arrangement in the immediate future, if > that does come to pass, it might behoove us to further standardize our > commentary for the various Mexican zones (in a similar manner as was done for > the many Russian zones in 2014). > Anyway, that puts the dividing line between the two resultant zones along the > border between the municipio of Guadalupe to the northwest and the municipios of > Coyame del Sotol and Ojinaga to the southeast …which meets the US border between > Barrio Alto and Presidio de Pilares, about 15 km south-southeast of my > (comparatively uninformed) guess, which I suppose wasn't all too bad for a > ~900-km-long border. Same in most European countries and Canadian provinces: https://en.wikipedia.org/wiki/Local_government_in_Canada#Regional_municipal… "Depending on the province, this second tier may be called a county, regional municipality, regional district or regional county municipality." There are also some district, island, mountain resort, resort, rural, and specialized municipalities, each of which may have varying geographic extents as an administrative chunk of a province. -- 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

[PROPOSED 1/4] Always define STD_INSPIRED
by Paul Eggert Nov. 30, 2022

Nov. 30, 2022

* private.h (STD_INSPIRED): Default to 0. All uses changed. This is purely refactoring, so that STD_INSPIRED is more like other macros in this file. --- Makefile | 2 +- localtime.c | 10 +++++----- private.h | 7 +++++-- theory.html | 2 +- 4 files changed, 12 insertions(+), 9 deletions(-) diff --git a/Makefile b/Makefile index 2c09f94..f0cbf7f 100644 --- a/Makefile +++ b/Makefile @@ -363,7 +363,7 @@ GCC_DEBUG_FLAGS = -DGCC_LINT -g3 -O3 -fno-common \ # -DNETBSD_INSPIRED=0 # to the end of the "CFLAGS=" line. Otherwise, the functions # "localtime_rz", "mktime_z", "tzalloc", and "tzfree" are added to the -# time library, and if STD_INSPIRED is also defined the functions +# time library, and if STD_INSPIRED is also defined to nonzero the functions # "posix2time_z" and "time2posix_z" are added as well. # The functions ending in "_z" (or "_rz") are like their unsuffixed # (or suffixed-by-"_r") counterparts, except with an extra first diff --git a/localtime.c b/localtime.c index 1d22d35..462d054 100644 --- a/localtime.c +++ b/localtime.c @@ -1697,7 +1697,7 @@ gmtime(const time_t *timep) return gmtime_r(timep, &tm); } -#ifdef STD_INSPIRED +#if STD_INSPIRED struct tm * offtime(const time_t *timep, long offset) @@ -1706,7 +1706,7 @@ offtime(const time_t *timep, long offset) return gmtsub(gmtptr, timep, offset, &tm); } -#endif /* defined STD_INSPIRED */ +#endif /* ** Return the number of leap years through the end of the given year @@ -2325,7 +2325,7 @@ mktime(struct tm *tmp) return t; } -#ifdef STD_INSPIRED +#if STD_INSPIRED time_t timelocal(struct tm *tmp) { @@ -2377,7 +2377,7 @@ leapcorr(struct state const *sp, time_t t) ** XXX--is the below the right way to conditionalize?? */ -#ifdef STD_INSPIRED +#if STD_INSPIRED /* NETBSD_INSPIRED_EXTERN functions are exported to callers if NETBSD_INSPIRED is defined, and are private otherwise. */ @@ -2462,7 +2462,7 @@ posix2time(time_t t) return t; } -#endif /* defined STD_INSPIRED */ +#endif /* STD_INSPIRED */ #if TZ_TIME_T diff --git a/private.h b/private.h index 9cb9c24..b5fdf5a 100644 --- a/private.h +++ b/private.h @@ -691,7 +691,10 @@ extern long altzone; ** declarations if time_tz is defined. */ -#ifdef STD_INSPIRED +#ifndef STD_INSPIRED +# define STD_INSPIRED 0 +#endif +#if STD_INSPIRED # if TZ_TIME_T || !defined offtime struct tm *offtime(time_t const *, long); # endif @@ -738,7 +741,7 @@ struct tm *localtime_rz(timezone_t restrict, time_t const *restrict, time_t mktime_z(timezone_t restrict, struct tm *restrict); timezone_t tzalloc(char const *); void tzfree(timezone_t); -# ifdef STD_INSPIRED +# if STD_INSPIRED # if TZ_TIME_T || !defined posix2time_z time_t posix2time_z(timezone_t, time_t) ATTRIBUTE_REPRODUCIBLE; # endif diff --git a/theory.html b/theory.html index 75e347f..f2b798b 100644 --- a/theory.html +++ b/theory.html @@ -1173,7 +1173,7 @@ The vestigial <abbr>API</abbr>s are: </li> <li> The functions that are conditionally compiled - if <code>STD_INSPIRED</code> is defined should, at this point, be + if <code>STD_INSPIRED</code> is nonzero should, at this point, be looked on primarily as food for thought. They are not in any sense "standard compatible" – some are not, in fact, specified in <em>any</em> standard. -- 2.38.1

1 3

New change in Mexico
by Heitor David Pinto Nov. 30, 2022

Nov. 30, 2022

Hello, Mexico is planning to change time zones again. Last month, the whole state of Chihuahua moved to UTC-6 without DST, causing a time change across the border with the US for part of the year. Now the northern municipalities want to have the same time zone as the respective neighboring cities in the US, for example Juárez in UTC-7 with DST, matching El Paso, and Ojinaga in UTC-6 with DST, matching Presidio. The congress of Chihuahua and the federal Chamber and Senate all approved the change, following the combined procedure specified in the new time zone law, and now it awaits the president's approval. The change should occur on the day after the official publication of the law, again on short notice.https://politica.expansion.mx/congreso/2022/11/24/aprueban-que-ayuntamientos-fronterizos-de-chihuahua-tengan-horario-de-verano But there is another problem. The actual law that was passed says that Juárez and Ojinaga will observe UTC-7 and UTC-6 during the DST period, not outside of it. I think that this was an oversight as a result of trying to pass the law through all the chambers very quickly, but I can't believe that no one noticed it. There is a legislative procedure in Mexico called "fe de erratas" to correct obvious mistakes without having to pass the law again, but in this case the correction would have to alter multiple sections so I'm not sure if it will be possible. Either way, I expect confusion in the next days.http://gaceta.diputados.gob.mx/PDF/65/2022/nov/20221124-VII.pdf Regards,Dave

5 12