- tz - lists.iana.org

[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