- tz - lists.iana.org

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: 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. + WMT Warsaw. -- 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