- tz - lists.iana.org

[tz-announce] 2022g release of tz code and data available
by Paul Eggert via tz-announce Nov. 29, 2022

Nov. 29, 2022

The 2022g release of the tz code and data is available. This release contains the following changes: Briefly: The northern edge of Chihuahua changes to US timekeeping. Much of Greenland stops changing clocks after March 2023. Fix some pre-1996 timestamps in northern Canada. C89 is now deprecated; please use C99 or later. Portability fixes for AIX, libintl, MS-Windows, musl, z/OS In C code, use more C23 features if available. C23 timegm now supported by default Fixes for unlikely integer overflows Changes to future timestamps In the Mexican state of Chihuahua, the border strip near the US will change to agree with nearby US locations on 2022-11-30. The strip's western part, represented by Ciudad Juárez, switches from -06 all year to -07/-06 with US DST rules, like El Paso, TX. The eastern part, represented by Ojinaga, will observe US DST next year, like Presidio, TX. (Thanks to Heitor David Pinto.) A new Zone America/Ciudad_Juarez splits from America/Ojinaga. Much of Greenland, represented by America/Nuuk, stops observing winter time after March 2023, so its daylight saving time becomes standard time. (Thanks to Jonas Nyrup and Jürgen Appel.) Changes to past timestamps Changes for pre-1996 northern Canada (thanks to Chris Walton): Merge America/Iqaluit and America/Pangnirtung into the former, with a backward compatibility link for the latter name. There is no good evidence the two locations differ since 1970. This change affects pre-1996 America/Pangnirtung timestamps. Cambridge Bay, Inuvik, Iqaluit, Rankin Inlet, Resolute and Yellowknife did not observe DST in 1965, and did observe DST from 1972 through 1979. Whitehorse moved from -09 to -08 on 1966-02-27, not 1967-05-28. Colombia's 1993 fallback was 02-06 24:00, not 04-04 00:00. (Thanks to Alois Treindl.) Singapore's 1981-12-31 change was at 16:00 UTC (23:30 local time), not 24:00 local time. (Thanks to Geoff Clare via Robert Elz.) Changes to code Although tzcode still works with C89, bugs found in recent routine maintenance indicate that bitrot has set in and that in practice C89 is no longer used to build tzcode. As it is a maintenance burden, support for C89 is planned to be removed soon. Instead, please use compilers compatible with C99, C11, C17, or C23. timegm, which tzcode implemented in 1989, will finally be standardized 34 years later as part of C23, so timegm is now supported even if STD_INSPIRED is not defined. Fix bug in zdump's tzalloc emulation on hosts that lack tm_zone. (Problem reported by Đoàn Trần Công Danh.) Fix bug in zic on hosts where malloc(0) yields NULL on success. (Problem reported by Tim McBrayer for AIX 6.1.) Fix zic configuration to avoid linkage failures on some platforms. (Problems reported by Gilmore Davidson and Igor Ivanov.) Work around MS-Windows nmake incompatibility with POSIX. (Problem reported by Manuela Friedrich.) Port mktime and strftime to debugging platforms where accessing uninitialized data has undefined behavior (strftime problem reported by Robert Elz). Check more carefully for unlikely integer overflows, preferring C23 <stdckdint.h> to overflow checking by hand, as the latter has had obscure bugs. Changes to build procedure New Makefile rule check_mild that skips checking whether Link lines are in the file 'backward'. (Inspired by a suggestion from Stephen Colebourne.) Here are links to the release files: https://www.iana.org/time-zones/repository/releases/tzcode2022g.tar.gz https://www.iana.org/time-zones/repository/releases/tzdata2022g.tar.gz https://www.iana.org/time-zones/repository/releases/tzdb-2022g.tar.lz The following convenience links are also available, although they may point to the previous release until the relevant caches are refreshed: https://www.iana.org/time-zones/repository/tzcode-latest.tar.gz https://www.iana.org/time-zones/repository/tzdata-latest.tar.gz https://www.iana.org/time-zones/repository/tzdb-latest.tar.lz Links are also available via plain HTTP, and via FTP from ftp://ftp.iana.org/tz/releases with the same basenames as above. Each release file has a GPG signature, which can be retrieved by appending ".asc" to the above URLs. Copies of these signatures are appended to this message. This release corresponds to commit 4e604e41115182c3ab1185bab4c888822511348e dated 2022-11-29 08:58:31 -0800 and tagged '2022g' in the development GitHub repository at <https://github.com/eggert/tz>. Here are the SHA-512 checksums for the release files: 5188edd8d05238a88da734cf78fadfb57640d4db3e7a0a9dddd70e3071e16b6eebc2e2ab17109b7dafafae68abfbc857df481cfdc3ffe63f7eb1569ea0b5997a tzcode2022g.tar.gz 7f79394295e00e3a24ebdbf9af3bc454a65f432a93b517e7e96c7f9db9949f6f5fdae9892a9d3789ff44ae0eb1bfe4744d36976b4624659af951d26414f94e65 tzdata2022g.tar.gz f471046189f519de5735ac2d8c3edb27cbe925247b06f44634e700e5e4453ec5f715d85256fc74d300bcdaa070a7600fcc054327f2dfe743ab3c0fe404ff83c1 tzdb-2022g.tar.lz Here are the GPG digital signatures for the release files: -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmOGOvAACgkQ7ZfpDmKq fjSI4w/+PkVPCILI34+QeXIm6LLPhEPLxtb7q3rvfoBXk/qyottcPJvQXSAsqX/c Hus6lCNK0COyICVn48rf3ss+GNxLev/ZTMVLUBkH8WrgSe+5lPDjmaZjkbzIGPs8 L9TqE60K8DyeLNnZPf4Pkpx6o5r7uO3iQSN5qFyj5H82mDJ4vcQLZSNvDIA4+sRm +qmsBcn6Gk3EU3u3/YrxhuEY0ymUrJvm5LSG62CqLwA1Pd+REF70Ir5LdO4yJoUS blWe/CLUcnRfzMEK9/NGa1z3GtkisPYBCPnYJ93m2n4ASvFQ+R3t7NCEY2W+96ce 3kSPIX5W2g0/gcDTi1bxdLnQkO4RxtSQnlCjCae58dQNUgOa2X8mdRniRjjYC059 JY35VUzmX9wCPpcuq0iMbpOEWXeWga0ZDRmlZtZCwPKxkw+AhoJQVp5jxGNa4kwZ CZDjQga3ObvN8aQqMi9TpabJ4m2ZdN1yHQ7OTN80N67tHYMAbW0aY3J0JRIVjTHo P+8Y6FaCLzJA73BgnR7faiILXIPtXE54X+koo8x2Uwtrl8/wHsaPTippq96ts6Y6 3Zdr3EAQgAPhYtUgtHoIbLFBLjmyL5sUXOTwG/gMkUYXVkDpeBnc+BHrkv0Sjaw7 Vzz5HthhnSblP9bLB3KPTbbM0t+aypsSOYOSZWnIK8ANI9BdrNQ= =tSyt -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmOGOvAACgkQ7ZfpDmKq fjSedhAAu8XkzqB8NmXDYfEurBCUPe7zCBxBe7yqdt5W+tDA9snOtab3d8Oq7Lsb vNZfh4qHIxNbEYpoXOc0Qce3XKXGgyKDmZeFYQJ0ziqoZXetNLQEmg7T/H2m3GHl eo7K3w2hvyBB26FuDtimE5pzuJo9qJLXDp2SbOAbKa1w5HibyvZBOfcQozZ4CBmE mBc8LzyFY3zOhiy7CGYskqOzatNa0Eid95RkK2RXXTnN965N1qdyOz3z9SkJFH9h MR84VGYBmk0UGdPGmp1imkGmIrO/8AFny19ECCe4F74o2DFSPzANOaEh+i3fIP3d GNR96la9GGopmna+VNQt6zxdw4DHRoNkAupnJ2NVM0lbAMOG0mmwCFkCzW4gzTVm 7NdAtZyH+HjiKYPdQNIHbsvl0K1qIo1yXrb4jTd8eXaxA65msCOOwjqWk7a8ZjrJ NrLNmGeLow9svofEAeLpc9BUgwF90JGIlb+tPYovyj/xSU9vhQl1ZEmFYYdaN781 rGZ5jKtwBZWoAxW1Copf8S3jcxleSVMFo6MTEU+K+svZLd8SH5BnETa0fYWSTzKA uh2Y4V6pFe0/JVVC15mYkytbP6TC6prRmi44jRHtVRDtizGd7FFxYacIApkhBVi2 Qb8Qy+oZySwL+dbRlu+bA9nHIdACtxRouVEWpAecCBLaK3kBb7I= =6g+2 -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmOGOvIACgkQ7ZfpDmKq fjT6/A/5AQdjRCEQngohVPQcxWE57FhHN+3Yq72iCbi64MhnL8sR+fHcni8CRb4f SIxi/tXeLdKJVV8+w7TBeQIDBDHrWXla2NSTHNcGREdp/wMoWagxBzAx3g2qQ7eT Qz6JhG4pHlOGK3u0/RESuCnhS/XmKTYj6BeDNc33LQ4iB0Lh+o9O/rz6jQyO3Y3L 84QMNJ4Edq/pOz9d9T1/cWO1j8Cn4Mled9WdCyOqZnhzRcJdbi/gDydC5aJIj1Fx 5OUrRwblIRVxMbK+kZA4D0lHR56KZb7NsaFGfsnW0m5zHUpXoGNYaFelKlWoRblO OEneM34IgNxsLhe9J9r/epSWB/14PmaY0zdXlNmKqELa7zYiJkiAwucPWtpxkPJG q6WPt4Pk4bWcud9esdgG7vjBz3ffrz2hUrmSMxuwLPHLuPRLrBoeMAmecFixGpea BUmR+XCPV9m19zcnvshBFGuLTNwFZSWBlUB9lWIocXc9cIMo4W/gNdUhnjb9L0+z VtAJzws1VcRV5zpkanwt+K50xjUlunxcRgLbLY2oMCpeDQyxH6DTnUr8RdJeMmvM ZPJYekxG0W8/eEjDOUFIQqvOtK1sQVhCZhjeciDW7to/K1p7DJy+g5g7lJn5KK4B Oz8vqmhdvdoIAK5uezPILpyJT7UpdUhmZ1WwQRqhk6G3jXPigQc= =Kyhr -----END PGP SIGNATURE-----

1 0

America/Nuuk changes from UTC-2 to UTC-2
by Jonas Nyrup Nov. 29, 2022

Nov. 29, 2022

On last Saturday in October 2023 when DST ends America/Nuuk will switch from -03/-02 to -02/-01 https://sermitsiaq.ag/forslagtidsforskel-danmark-mindskes-sommertid-beholdes describes the proposed bill about switching from UTC-3 to UTC-2 and that is not about abolishing DST as they do not want to make a decision on that matter before the rest of EU. https://sermitsiaq.ag/groenland-skifte-tidszone-trods-bekymringer writes that on November 24th 2022 the Parliament of Greenland approved the bill and that *the bill* will take effect on March 25th 2023 at 22:00 when DST begins. Both articles translates well with Google Translate. Inatsisartut = the Parliament of Greenland Naalakkersuisut = the government of Greenland I assume the official document will be published on https://naalakkersuisut.gl/kundgoerelser/2022?sc_lang=da Best regards Jonas Nyrup

2 2

[PROPOSED 0/5] Finish off support for C23 standard attributes
by Paul Eggert Nov. 28, 2022

Nov. 28, 2022

The attached patches update tzcode to use the remaining C23 standard attributes that look useful for tzcode. I don't see any tzcode use for the C23 attributes 'deprecated' and 'nodiscard'. Paul Eggert (5): Use C23 [[noreturn]] if available Pacify gcc -std=c89 -pedantic with new attributes Use C23 [[reproducible]] if available. Use C23 [[unsequenced]] if available Use C23 [[fallthrough]] if available Makefile | 2 +- date.c | 2 +- localtime.c | 4 +-- private.h | 77 ++++++++++++++++++++++++++++++++++++++++++++--------- zdump.c | 10 +++---- zic.c | 32 +++++++++++----------- 6 files changed, 90 insertions(+), 37 deletions(-) -- 2.37.2

2 7

Doubts about a typo fix
by Alejandro Colomar Nov. 26, 2022

Nov. 26, 2022

Hi Paul, I don't undertstand the commit shown below. It breaks the '-' symbol, which now is a hyphen. See the table mentioned yesterday: ┌──────────────────────────────────────────────────────────────────┐ │Keycap Appearance and meaning Special character and meaning │ ├──────────────────────────────────────────────────────────────────┤ │" " neutral double quote \[dq] neutral double quote │ │' ’ closing single quote \[aq] neutral apostrophe │ │- ‐ hyphen \- or \[-] minus sign/Unix dash │ │\ (escape character) \e or \[rs] reverse solidus │ │^ ˆ modifier circumflex \(ha circumflex/caret/“hat” │ │` ‘ opening single quote \(ga grave accent │ │~ ˜ modifier tilde \(ti tilde │ └──────────────────────────────────────────────────────────────────┘ So, at least, it should be (but I believe the initial code was correct): .q "zic \*\-r @$(date +%s)" However, I wonder what that \* is intending to do there (I can see no difference in my screen with or without it). Cheers, Alex --- commit 918e10e8963b3c0d38d3b5fb8ec9cf08ecd03757 Author: Paul Eggert <eggert(a)cs.ucla.edu> Date: Tue Jul 12 06:26:53 2022 -0700 * zic.8: fix minus typo diff --git a/zic.8 b/zic.8 index 0cd0781e..e8816e5b 100644 --- a/zic.8 +++ b/zic.8 @@ -145,7 +145,7 @@ .SH OPTIONS 31-bit signed integers. On platforms with GNU .BR date , -.q "zic \-r @$(date +%s)" +.q "zic \*-r @$(date +%s)" omits data intended for past timestamps. Although this option typically reduces the output file's size, the size can increase due to the need to represent the timestamp range -- <http://www.alejandro-colomar.es/>

5 7

New law about Time and Time zones in Greenland
by Jürgen Appel Nov. 25, 2022

Nov. 25, 2022

Dear all, i was made aware that on Thursday, 2022-11-24, a law proposal concerning time and time zones for Greenland was voted upon in Greenland Parliament: Reference (in Danish and Greenlandic): https://ina.gl/samlinger/oversigt-over-samlinger/samling/dagsordener/ dagsorden.aspx?lang=da&day=24-11-2022 https://ina.gl/media/2553527/pkt17_em2022_tidens_-bestemmelse_lov_da.pdf Translated with www.DeepL.com/Translator and annotated: =====[Proposal]===== Inatsisartut (Parliament of Greenland) Act on the Regulation of Time § 1. The standard time for Greenland shall be UTC -2. Clause 2. Naalakkersuisut (the Cabinet of Greenland) may establish rules that specified areas shall follow a different time zone than that determined in paragraph 1. Clause 3. Naalakkersuisut may establish rules on summer time. § 2. This Inatsisartut Act shall enter into force on 25 March 2023 at 22:00. Clause 2. At the same time, Landstingslov nr. 14 of 19 October 1989 regarding the application of summer time is repealed. Greenland Self-Government, x. xx xxx The President of Naalakkersuisut =================== If I understand this correctly, from the next planned switch to summer time, Greenland will permanently stay at that time, i.e. no switch back to winter time in 2023 will occur. Whether a switch to a shifted summer time will occur in spring 2024 is not completely transparent to me, as in some remarks (https://ina.gl/media/ 2554772/pkt17_em2022_tidens_bestemmelse_bet_2beh_da.pdf) it is written that no changes in the summer time regulations will be applied, and that this will occur only after EU has decided about the same topic. If some danish native speaker, or better yet someone from Greenland could confirm/clarify this, that would be nice. Also concerning "specified areas", i.e. today Ittoqqortoormiit (now UTC -1), Danmarkshavn (UTC +0), and Pituffik/Thule Air Base (UTC-4), I am unsure whether any changes are scheduled or whether the cabinet plans to keep/ reestablish the current rules. Best regards, Jürgen Appel -- Jürgen Appel Senior Scientist Denmark's National Metrology Institute Dansk Fundamental Metrologi, DFM A/S (dfm.dk) Kogle Allé 5 DK-2970 Hørsholm Denmark Mobile: +45 25459049 Email: jap(a)dfm.dk VAT: DK-29217939

2 1

Re: [tz] [PATCH v2 1/4] zic.8: Add public domain notice
by Brian Inglis Nov. 25, 2022

Nov. 25, 2022

On 2022-11-23 11:32, Paul Eggert via tz wrote: > The file already contains a public-domain notice at the bottom, in a > human-readable format that is visible to anybody who looks at the printable > version of the man page. No public domain notices appear in the *.?.txt source files or in the generated man pages. It may be useful to specify that the document, data, program, and source files for all components are in the public domain in the LICEN[CS]E sections. It would also be useful if you also added SPDX licence comments like man-pages after either your line(s) or theirs, such as: .\" SPDX-License-Identifier: LicenseRef-IANA-TZ-Public-Domain [suggested] .\" SPDX-FileCopyrightText: project authors [suggested] and also in the generated output?, as it may save downstreams doing so as licensing requirements are enforced by packaging tools and repos. -- 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

2 1

[PROPOSED] Use C23 [[maybe_unused]] if available
by Paul Eggert Nov. 21, 2022

Nov. 21, 2022

* Makefile (GCC_DEBUG_FLAGS): Omit -Wno-unused-parameters, as the code is now safe for gcc -Wunused-parameters. * private.h (ATTRIBUTE_MAYBE_UNUSED): New macro. * localtime.c (gmtsub): * strftime.c (strftime_l) [HAVE_STRFTIME_L]: * zdump.c (gmtoff): Use it to mark possibly-unused parameters. * zdump.c (hunt): * zic.c (getleapdatetime): Omit unused arg. All callers changed. --- Makefile | 2 +- localtime.c | 4 ++-- private.h | 13 +++++++++++++ strftime.c | 2 +- zdump.c | 13 +++++++------ zic.c | 6 +++--- 6 files changed, 27 insertions(+), 13 deletions(-) diff --git a/Makefile b/Makefile index 92d78cb4..b2c6ff6f 100644 --- a/Makefile +++ b/Makefile @@ -300,7 +300,7 @@ GCC_DEBUG_FLAGS = -DGCC_LINT -g3 -O3 -fno-common \ -Wtrampolines -Wundef -Wuninitialized -Wunused-macros -Wuse-after-free=3 \ -Wvariadic-macros -Wvla -Wwrite-strings \ -Wno-address -Wno-format-nonliteral -Wno-sign-compare \ - -Wno-type-limits -Wno-unused-parameter + -Wno-type-limits # # If your system has a "GMT offset" field in its "struct tm"s # (or if you decide to add such a field in your system's "time.h" file), diff --git a/localtime.c b/localtime.c index 7faa5d32..4dd9d259 100644 --- a/localtime.c +++ b/localtime.c @@ -1662,8 +1662,8 @@ localtime_r(const time_t *timep, struct tm *tmp) */ static struct tm * -gmtsub(struct state const *sp, time_t const *timep, int_fast32_t offset, - struct tm *tmp) +gmtsub(ATTRIBUTE_MAYBE_UNUSED struct state const *sp, time_t const *timep, + int_fast32_t offset, struct tm *tmp) { register struct tm * result; diff --git a/private.h b/private.h index 4d40582e..fee18cb2 100644 --- a/private.h +++ b/private.h @@ -433,6 +433,19 @@ typedef unsigned long uintmax_t; # define ATTRIBUTE_FORMAT(spec) /* empty */ #endif +#ifdef __has_c_attribute +# if __has_c_attribute(__maybe_unused__) +# define ATTRIBUTE_MAYBE_UNUSED [[__maybe_unused__]] +# endif +#endif +#ifndef ATTRIBUTE_MAYBE_UNUSED +# if 2 < __GNUC__ + (7 <= __GNUC_MINOR__) +# define ATTRIBUTE_MAYBE_UNUSED __attribute__ ((__unused__)) +# else +# define ATTRIBUTE_MAYBE_UNUSED /* empty */ +# endif +#endif + #if !defined _Noreturn && __STDC_VERSION__ < 201112 # if 2 < __GNUC__ + (8 <= __GNUC_MINOR__) # define _Noreturn __attribute__((__noreturn__)) diff --git a/strftime.c b/strftime.c index 9ea40fec..b23b6101 100644 --- a/strftime.c +++ b/strftime.c @@ -117,7 +117,7 @@ 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, - locale_t locale) + ATTRIBUTE_MAYBE_UNUSED locale_t locale) { /* Just call strftime, as only the C locale is supported. */ return strftime(s, maxsize, format, t); diff --git a/zdump.c b/zdump.c index 89bcd25c..de1e1116 100644 --- a/zdump.c +++ b/zdump.c @@ -91,7 +91,7 @@ static bool errout; static char const *abbr(struct tm const *); static intmax_t delta(struct tm *, struct tm *) ATTRIBUTE_PURE; static void dumptime(struct tm const *); -static time_t hunt(timezone_t, char *, time_t, time_t, bool); +static time_t hunt(timezone_t, time_t, time_t, bool); static void show(timezone_t, char *, time_t, bool); static void showextrema(timezone_t, char *, time_t, struct tm *, time_t); static void showtrans(char const *, struct tm const *, time_t, char const *, @@ -627,7 +627,7 @@ main(int argc, char *argv[]) || (ab && (delta(&newtm, &tm) != newt - t || newtm.tm_isdst != tm.tm_isdst || strcmp(abbr(&newtm), ab) != 0))) { - newt = hunt(tz, argv[i], t, newt, false); + newt = hunt(tz, t, newt, false); newtmp = localtime_rz(tz, &newt, &newtm); newtm_ok = newtmp != NULL; if (iflag) @@ -707,7 +707,7 @@ yeartot(intmax_t y) return t; } -/* Search for a discontinuity in timezone TZ with name NAME, in the +/* Search for a discontinuity in timezone TZ, in the timestamps ranging from LOT through HIT. LOT and HIT disagree about some aspect of timezone. If ONLY_OK, search only for definedness changes, i.e., localtime succeeds on one side of the @@ -715,7 +715,7 @@ yeartot(intmax_t y) before the transition from LOT's settings. */ static time_t -hunt(timezone_t tz, char *name, time_t lot, time_t hit, bool only_ok) +hunt(timezone_t tz, time_t lot, time_t hit, bool only_ok) { static char * loab; static ptrdiff_t loabsize; @@ -807,7 +807,8 @@ adjusted_yday(struct tm const *a, struct tm const *b) my_gmtime_r and use its result instead of B. Otherwise, B is the possibly nonnull result of an earlier call to my_gmtime_r. */ static long -gmtoff(struct tm const *a, time_t *t, struct tm const *b) +gmtoff(struct tm const *a, ATTRIBUTE_MAYBE_UNUSED time_t *t, + ATTRIBUTE_MAYBE_UNUSED struct tm const *b) { #ifdef TM_GMTOFF return a->TM_GMTOFF; @@ -878,7 +879,7 @@ static void showextrema(timezone_t tz, char *zone, time_t lo, struct tm *lotmp, time_t hi) { struct tm localtm[2], gmtm[2]; - time_t t, boundary = hunt(tz, zone, lo, hi, true); + time_t t, boundary = hunt(tz, lo, hi, true); bool old = false; hi = (SECSPERDAY < hi - boundary ? boundary + SECSPERDAY diff --git a/zic.c b/zic.c index 8f8088ec..7a7a5094 100644 --- a/zic.c +++ b/zic.c @@ -1970,7 +1970,7 @@ inzsub(char **fields, int nfields, bool iscont) } static zic_t -getleapdatetime(char **fields, int nfields, bool expire_line) +getleapdatetime(char **fields, bool expire_line) { register const char * cp; register const struct lookup * lp; @@ -2048,7 +2048,7 @@ inleap(char **fields, int nfields) if (nfields != LEAP_FIELDS) error(_("wrong number of fields on Leap line")); else { - zic_t t = getleapdatetime(fields, nfields, false); + zic_t t = getleapdatetime(fields, false); if (0 <= t) { struct lookup const *lp = byword(fields[LP_ROLL], leap_types); if (!lp) @@ -2076,7 +2076,7 @@ inexpires(char **fields, int nfields) else if (0 <= leapexpires) error(_("multiple Expires lines")); else - leapexpires = getleapdatetime(fields, nfields, true); + leapexpires = getleapdatetime(fields, true); } static void -- 2.37.2

2 2

[PROPOSED] Prefer <stdckdint.h> for overflow checking
by Paul Eggert Nov. 20, 2022

Nov. 20, 2022

If <stdckdint.h> is available, or if its macros can be implemented easily, use the macros for overflow checking. This should help avoid future integer overflow bugs. * date.c (dogmt, timeout): * localtime.c (localsub, timesub, increment_overflow) (increment_overflow32, increment_overflow_time, time2sub): * zdump.c (sumsize, tzalloc): * zic.c (size_sum, size_product, grow_nitems_alloc, oadd, tadd): Prefer ckd_add etc. to doing overflow checking by hand. * private.h (HAVE_STDCKDINT_H): Default to true if __has_include(<stdckdint.h>). Include <stdckdint.h> if available. (ckd_add, ckd_sub, ckd_mul): Provide substitutes on recent-enough GCC-compatible compilers. --- Makefile | 2 ++ NEWS | 5 ++++- date.c | 10 ++++++++++ localtime.c | 33 +++++++++++++++++++++++++++++++++ private.h | 29 +++++++++++++++++++++++++++++ zdump.c | 12 ++++++++++++ zic.c | 31 +++++++++++++++++++++++++++++++ 7 files changed, 121 insertions(+), 1 deletion(-) diff --git a/Makefile b/Makefile index 5ec0d4a..92d78cb 100644 --- a/Makefile +++ b/Makefile @@ -230,6 +230,8 @@ LDLIBS= # 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_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_STRFTIME_L if <time.h> declares locale_t and strftime_l # -DHAVE_STRDUP=0 if your system lacks the strdup function diff --git a/NEWS b/NEWS index 7c46d3c..a401bee 100644 --- a/NEWS +++ b/NEWS @@ -4,6 +4,7 @@ News for the tz database Fix some pre-1996 timestamps in northern Canada. C89 is now deprecated; please use C99 or later. Portability fixes for AIX, libintl, MS-Windows, musl, z/OS + In C code, use more C23 features if available. C23 timegm now supported by default Fixes for unlikely integer overflows @@ -55,7 +56,9 @@ Unreleased, experimental changes uninitialized data has undefined behavior (strftime problem reported by Robert Elz). - Check more carefully for unlikely integer overflows. + Check more carefully for unlikely integer overflows, preferring + C23 <stdckdint.h> to overflow checking by hand, as the latter has + had obscure bugs. Changes to build procedure diff --git a/date.c b/date.c index cbc0ec1..1319462 100644 --- a/date.c +++ b/date.c @@ -122,8 +122,14 @@ dogmt(void) for (n = 0; environ[n] != NULL; ++n) continue; +#if defined ckd_add && defined ckd_mul + if (!ckd_add(&n, n, 2) && !ckd_mul(&n, n, sizeof *fakeenv) + && n <= SIZE_MAX) + fakeenv = malloc(n); +#else if (n <= min(PTRDIFF_MAX, SIZE_MAX) / sizeof *fakeenv - 2) fakeenv = malloc((n + 2) * sizeof *fakeenv); +#endif if (fakeenv == NULL) { fprintf(stderr, _("date: Memory exhausted\n")); errensure(); @@ -187,8 +193,12 @@ timeout(FILE *fp, char const *format, struct tm const *tmp) ptrdiff_t size = 1024 / 2; for ( ; ; ) { +#ifdef ckd_mul + bool bigger = !ckd_mul(&size, size, 2) && size <= SIZE_MAX; +#else bool bigger = (size <= min(PTRDIFF_MAX, SIZE_MAX) / 2 && (size *= 2, true)); +#endif char *newcp = bigger ? realloc(cp, size) : NULL; if (!newcp) { fprintf(stderr, diff --git a/localtime.c b/localtime.c index 7326567..7faa5d3 100644 --- a/localtime.c +++ b/localtime.c @@ -1565,6 +1565,14 @@ localsub(struct state const *sp, time_t const *timep, int_fast32_t setname, return NULL; /* "cannot happen" */ result = localsub(sp, &newt, setname, tmp); if (result) { +#if defined ckd_add && defined ckd_sub + if (t < sp->ats[0] + ? ckd_sub(&result->tm_year, + result->tm_year, years) + : ckd_add(&result->tm_year, + result->tm_year, years)) + return NULL; +#else register int_fast64_t newy; newy = result->tm_year; @@ -1574,6 +1582,7 @@ localsub(struct state const *sp, time_t const *timep, int_fast32_t setname, if (! (INT_MIN <= newy && newy <= INT_MAX)) return NULL; result->tm_year = newy; +#endif } return result; } @@ -1783,6 +1792,12 @@ timesub(const time_t *timep, int_fast32_t offset, y = newy; } +#ifdef ckd_add + if (ckd_add(&tmp->tm_year, y, -TM_YEAR_BASE)) { + errno = EOVERFLOW; + return NULL; + } +#else if (!TYPE_SIGNED(time_t) && y < TM_YEAR_BASE) { int signed_y = y; tmp->tm_year = signed_y - TM_YEAR_BASE; @@ -1793,6 +1808,7 @@ timesub(const time_t *timep, int_fast32_t offset, errno = EOVERFLOW; return NULL; } +#endif tmp->tm_yday = idays; /* ** The "extra" mods below avoid overflow problems. @@ -1867,6 +1883,9 @@ ctime_r(const time_t *timep, char *buf) static bool increment_overflow(int *ip, int j) { +#ifdef ckd_add + return ckd_add(ip, *ip, j); +#else register int const i = *ip; /* @@ -1879,22 +1898,30 @@ increment_overflow(int *ip, int j) return true; *ip += j; return false; +#endif } static bool increment_overflow32(int_fast32_t *const lp, int const m) { +#ifdef ckd_add + return ckd_add(lp, *lp, m); +#else register int_fast32_t const l = *lp; if ((l >= 0) ? (m > INT_FAST32_MAX - l) : (m < INT_FAST32_MIN - l)) return true; *lp += m; return false; +#endif } static bool increment_overflow_time(time_t *tp, int_fast32_t j) { +#ifdef ckd_add + return ckd_add(tp, *tp, j); +#else /* ** This is like ** 'if (! (TIME_T_MIN <= *tp + j && *tp + j <= TIME_T_MAX)) ...', @@ -1906,6 +1933,7 @@ increment_overflow_time(time_t *tp, int_fast32_t j) return true; *tp += j; return false; +#endif } static bool @@ -2029,11 +2057,16 @@ time2sub(struct tm *const tmp, return WRONG; } } +#ifdef ckd_add + if (ckd_add(&yourtm.tm_year, y, -TM_YEAR_BASE)) + return WRONG; +#else if (increment_overflow32(&y, -TM_YEAR_BASE)) return WRONG; if (! (INT_MIN <= y && y <= INT_MAX)) return WRONG; yourtm.tm_year = y; +#endif if (yourtm.tm_sec >= 0 && yourtm.tm_sec < SECSPERMIN) saved_seconds = 0; else if (yourtm.tm_year < EPOCH_YEAR - TM_YEAR_BASE) { diff --git a/private.h b/private.h index 4315a85..4d40582 100644 --- a/private.h +++ b/private.h @@ -392,6 +392,35 @@ typedef unsigned long uintmax_t; # define SIZE_MAX ((size_t) -1) #endif +/* 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 +# if __has_include(<stdckdint.h>) +# define HAVE_STDCKDINT_H true +# endif +#endif +#ifdef HAVE_STDCKDINT_H +# if HAVE_STDCKDINT_H +# include <stdckdint.h> +# endif +#elif defined __EDG__ +/* Do nothing, to work around EDG bug <https://bugs.gnu.org/53256>. */ +#elif defined __has_builtin +# if __has_builtin(__builtin_add_overflow) +# define ckd_add(r, a, b) __builtin_add_overflow(a, b, r) +# endif +# if __has_builtin(__builtin_sub_overflow) +# define ckd_sub(r, a, b) __builtin_sub_overflow(a, b, r) +# endif +# if __has_builtin(__builtin_mul_overflow) +# define ckd_mul(r, a, b) __builtin_mul_overflow(a, b, r) +# endif +#elif 7 <= __GNUC__ +# define ckd_add(r, a, b) __builtin_add_overflow(a, b, r) +# define ckd_sub(r, a, b) __builtin_sub_overflow(a, b, r) +# define ckd_mul(r, a, b) __builtin_mul_overflow(a, b, r) +#endif + #if 3 <= __GNUC__ # define ATTRIBUTE_CONST __attribute__((const)) # define ATTRIBUTE_MALLOC __attribute__((__malloc__)) diff --git a/zdump.c b/zdump.c index 669d8fd..89bcd25 100644 --- a/zdump.c +++ b/zdump.c @@ -137,9 +137,15 @@ size_overflow(void) static ATTRIBUTE_PURE ptrdiff_t sumsize(size_t a, size_t b) { +#ifdef ckd_add + ptrdiff_t sum; + if (!ckd_add(&sum, a, b) && sum <= SIZE_MAX) + return sum; +#else ptrdiff_t sum_max = min(PTRDIFF_MAX, SIZE_MAX); if (a <= sum_max && b <= sum_max - a) return a + b; +#endif size_overflow(); } @@ -254,9 +260,15 @@ tzalloc(char const *val) ptrdiff_t initial_nenvptrs = 1; /* Counting the trailing NULL pointer. */ while (*e++) { +# ifdef ckd_add + if (ckd_add(&initial_nenvptrs, initial_envptrs, 1) + || SIZE_MAX < initial_envptrs) + size_overflow(); +# else if (initial_nenvptrs == min(PTRDIFF_MAX, SIZE_MAX) / sizeof *environ) size_overflow(); initial_nenvptrs++; +# endif } fakeenv0size = sumsize(valsize, valsize); fakeenv0size = max(fakeenv0size, 64); diff --git a/zic.c b/zic.c index a69d4e0..8f8088e 100644 --- a/zic.c +++ b/zic.c @@ -475,18 +475,30 @@ size_overflow(void) static ATTRIBUTE_PURE ptrdiff_t size_sum(size_t a, size_t b) { +#ifdef ckd_add + ptrdiff_t sum; + if (!ckd_add(&sum, a, b) && sum <= SIZE_MAX) + return sum; +#else ptrdiff_t sum_max = min(PTRDIFF_MAX, SIZE_MAX); if (a <= sum_max && b <= sum_max - a) return a + b; +#endif size_overflow(); } static ATTRIBUTE_PURE ptrdiff_t size_product(ptrdiff_t nitems, ptrdiff_t itemsize) { +#ifdef ckd_mul + ptrdiff_t product; + if (!ckd_mul(&product, nitems, itemsize) && product <= SIZE_MAX) + return product; +#else ptrdiff_t nitems_max = min(PTRDIFF_MAX, SIZE_MAX) / itemsize; if (nitems <= nitems_max) return nitems * itemsize; +#endif size_overflow(); } @@ -536,11 +548,18 @@ static ptrdiff_t grow_nitems_alloc(ptrdiff_t *nitems_alloc, ptrdiff_t itemsize) { ptrdiff_t addend = (*nitems_alloc >> 1) + 1; +#if defined ckd_add && defined ckd_mul + ptrdiff_t product; + if (!ckd_add(nitems_alloc, *nitems_alloc, addend) + && !ckd_mul(&product, *nitems_alloc, itemsize) && product <= SIZE_MAX) + return product; +#else ptrdiff_t amax = min(PTRDIFF_MAX, SIZE_MAX); if (*nitems_alloc <= ((amax - 1) / 3 * 2) / itemsize) { *nitems_alloc += addend; return *nitems_alloc * itemsize; } +#endif memory_exhausted(_("integer overflow")); } @@ -3716,16 +3735,28 @@ time_overflow(void) static ATTRIBUTE_PURE zic_t oadd(zic_t t1, zic_t t2) { +#ifdef ckd_add + zic_t sum; + if (!ckd_add(&sum, t1, t2)) + return sum; +#else if (t1 < 0 ? ZIC_MIN - t1 <= t2 : t2 <= ZIC_MAX - t1) return t1 + t2; +#endif time_overflow(); } static ATTRIBUTE_PURE zic_t tadd(zic_t t1, zic_t t2) { +#ifdef ckd_add + zic_t sum; + if (!ckd_add(&sum, t1, t2) && min_time <= sum && sum <= max_time) + return sum; +#else if (t1 < 0 ? min_time - t1 <= t2 : t2 <= max_time - t1) return t1 + t2; +#endif if (t1 == min_time || t1 == max_time) return t1; time_overflow(); -- 2.38.1

1 0

[PROPOSED 0/6] unlikely integer overflow fixes
by Paul Eggert Nov. 20, 2022

Nov. 20, 2022

This patch set fixes some unlikely integer overflow bugs. These patches are relevant only for unusual situations, e.g., objects so large that their sizes exceed PTRDIFF_MAX bytes; or for unusual architectures, e.g., architectures where INT_MAX == UINT_MAX. In most cases I do not know of any practical way to exploit the bug, even if POSIX says the bug is possible. Paul Eggert (6): Don’t assume INT_MAX < UINT_FAST64_MAX Fix size_t overflow check if SIZE_MAX == INT_MAX date: integer overflow fixes Improve integer overflow checking in zdump Fix theoretical integer overflow in zic.c Fix another theoretical zic.c overflow NEWS | 3 ++ date.c | 32 +++++++------------ private.h | 4 +++ zdump.c | 64 +++++++++++++++++++++----------------- zic.c | 92 +++++++++++++++++++++++++++++++++++-------------------- 5 files changed, 113 insertions(+), 82 deletions(-) -- 2.38.1

1 6

[PATCH 1/5] Simplify inputline return value
by Paul Eggert Nov. 20, 2022

Nov. 20, 2022

* zic.c (inputline): Return bool, not ptrdiff_t. All callers changed. --- zic.c | 13 +++++-------- 1 file changed, 5 insertions(+), 8 deletions(-) diff --git a/zic.c b/zic.c index 548c1c5..0671889 100644 --- a/zic.c +++ b/zic.c @@ -1575,10 +1575,9 @@ associate(void) /* Read a text line from FP into BUF, which is of size BUFSIZE. Terminate it with a NUL byte instead of a newline. - Return the line's length, not counting the NUL byte. - On EOF, return a negative number. + Return true if successful, false if EOF. On error, report the error and exit. */ -static ptrdiff_t +static bool inputline(FILE *fp, char *buf, ptrdiff_t bufsize) { ptrdiff_t linelen = 0, ch; @@ -1589,7 +1588,7 @@ inputline(FILE *fp, char *buf, ptrdiff_t bufsize) exit(EXIT_FAILURE); } if (linelen == 0) - return -1; + return false; error(_("unterminated line")); exit(EXIT_FAILURE); } @@ -1604,7 +1603,7 @@ inputline(FILE *fp, char *buf, ptrdiff_t bufsize) } } buf[linelen] = '\0'; - return linelen; + return true; } static void @@ -1626,13 +1625,11 @@ infile(int fnum, char const *name) } wantcont = false; for (num = 1; ; ++num) { - ptrdiff_t linelen; char buf[_POSIX2_LINE_MAX]; int nfields; char *fields[MAX_FIELDS]; eat(fnum, num); - linelen = inputline(fp, buf, sizeof buf); - if (linelen < 0) + if (!inputline(fp, buf, sizeof buf)) break; nfields = getfields(buf, fields, sizeof fields / sizeof *fields); -- 2.38.1

1 4

[PROPOSED 0/4] Port to C89, and deprecate C89
by Paul Eggert Nov. 19, 2022

Nov. 19, 2022

While looking into fixing some bugs in tzcode, I noticed some places where existing code wouldn’t work with ancient C89 compilers. I fixed the problems I found in this patch series. Quite possibly other problems remain, problems that I didn’t notice. As nobody has reported C89-related problems for ages, it appears that these old compilers are no longer being used to compile tzcode. So I propose that we remove C89 support, to avoid future maintenance burdens such as the one I recently went through. As part of the transition away from C89 support, the last patch in this series announces that C89 will be removed in some future release. We can keep C89 support for at least one release longer. Paul Eggert (4): Port to C89 gcc -pedantic Port UINT_FAST64_MAX back to C89 Port int_fast64_t to C89 64-bit long * NEWS: Deprecate C89. NEWS | 7 +++++++ private.h | 47 +++++++++++++++++++++++------------------------ 2 files changed, 30 insertions(+), 24 deletions(-) -- 2.38.1

1 4

Re: [tz] Country name change from Turkey to Turkiye
by Brian Inglis Nov. 19, 2022

Nov. 19, 2022

On 2022-11-17 23:09, Bin Li via tz wrote: > Do you have any plans to change Turkey's name? Because it's the official name now. > https://www.npr.org/2022/06/03/1102841197/turkey-changes-its-official-name-… <https://www.npr.org/2022/06/03/1102841197/turkey-changes-its-official-name-…> One of the stupider ISO decisions, as English supports no accents, except in loanwords, and they are just ignored, except possibly in academic publishing. I think it is time native English language speakers push back against and ignore decisions made by international committees of non-native English language speakers, to try and change what native English language speakers use to what the foreign language uses in Latin alphabet transliterations, just as the other 100+ countries who have no "official" transliteration do. -- 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

3 2

Country name change from Turkey to Turkiye
by Bin Li Nov. 18, 2022

Nov. 18, 2022

Dear, Do you have any plans to change Turkey's name? Because it's the official name now. https://www.npr.org/2022/06/03/1102841197/turkey-changes-its-official-name-…

6 8

New York Times: Time is Running Out for the Leap Second
by Jonathan Leffler Nov. 15, 2022

Nov. 15, 2022

https://www.nytimes.com/2022/11/14/science/time-leap-second.html -- Jonathan Leffler <jonathan.leffler(a)gmail.com> #include <disclaimer.h> Guardian of DBD::Informix - v2018.1031 - http://dbi.perl.org "Blessed are we who can laugh at ourselves, for we shall never cease to be amused."

1 0

United States Senate reintroduced Sunshine Protection Act, enabling Permanent DST
by Phake Nick Nov. 14, 2022

Nov. 14, 2022

I don't quite understand the legal text of the bill itself [2], but according to my reading, it seems like the bill will end DST across the entire US by shifting the standard time forward an hour, except in states/territories/area that currently doesn't enact DST, which they can choose to follow the new standard time or old standard time? 1: https://www.rubio.senate.gov/public/index.cfm/2021/3/rubio-colleagues-reint… 2: https://www.rubio.senate.gov/public/_cache/files/d34c77c0-acea-4074-bc57-14…

18 26

[PATCH] use official source for 1993 end of time shift
by Alois Treindl Nov. 12, 2022

Nov. 12, 2022

--- southamerica | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/southamerica b/southamerica index 13cc65e..8eb5e25 100644 --- a/southamerica +++ b/southamerica @@ -1417,10 +1417,13 @@ Zone Antarctica/Palmer 0 - -00 1965 # Milne gives 4:56:16.4 for Bogotá time in 1899. He writes, # "A variation of fifteen minutes in the public clocks of Bogota is not rare." +# Alois Treindl quoted DECRETO 267 DE 1993 +# https://www.suin-juriscol.gov.co/viewDocument.asp?ruta=Decretos/1061335 +# Artículo 2° El cambio de hora se hará efectivo a las veinticuatro horas del día 6 de febrero del presente año. # Rule NAME FROM TO - IN ON AT SAVE LETTER/S Rule CO 1992 only - May 3 0:00 1:00 - -Rule CO 1993 only - Apr 4 0:00 0 - +Rule CO 1993 only - Feb 7 0:00 0 - # Zone NAME STDOFF RULES FORMAT [UNTIL] #STDOFF -4:56:16.4 Zone America/Bogota -4:56:16 - LMT 1884 Mar 13 -- 1.8.3.1

2 1

Re: [tz] Minor (unimportant really) technical UB bug in strftime() ?
by Brian Inglis Nov. 12, 2022

Nov. 12, 2022

On 2022-11-11 13:53, Paul Eggert via tz wrote: > On 2022-11-10 16:11, Tom Lane wrote: > >> simple modifications of the >> strftime() case can provide pretty good examples. > I'm not sure I'm following this argument, but if I understand it correctly I > disagree. I very much much want implementations to reject attempts to use > uninitialized data, and I don't want the C standard to prohibit such > implementations. Use of uninitialized data is a serious problem in real > applications - several CVEs have arisen from it - and the C standard shouldn't > require implementations to sweep it under the rug. > This call is obviously buggy since it is passing an uninitialized struct tm to > strftime. However, the C standard says the patched strftime's memcpy initializes > strftime's local variable tm, and therefore mktime's use of tm's contents is > defined and the implementation allow the program's use of uninitialized data. > > Whatever the reason for this peculiarity of the C standard (and nobody seems to > remember why it's there), it's counterproductive. In general C programs > shouldn't use uninitialized data. If they do, it's useful to have a debugging > implementation that reports any such use the instant that it happens as this > will help catch real bugs. And since common debugging implementations like > valgrind and UBSan are not following the C standard here, this suggests that the > C standard is mistaken, not the implementations. >> That leads either to strftime() knowing >> much more about mktime()'s innards than it ought to > It's not a problem for strftime, since strftime's has to know what's needed in > the struct tm; this follows from strftime's API. It may not know everything about the object, as there may be implementatiion extensions to deal with e.g. localization issues, and can never know everything about another function implementation, which could be changed at any time. > It might be a problem for other scenarios, such as the one you vaguely suggested > though I don't know the details. However, even assuming these other scenarios > exist, they don't justify this peculiarity of the C standard. The standard > should not say that the ordinary meaning of "don't use uninitialized variables" > is wrong and that there's some trickier interpretation that hardly any > programmer knows and that was wrong even in C17 and so needed rewording (and > perhaps still needs rewording) and that nevertheless must be supported - even > though important debugging implementations disagree. I think the principle is just to program carefully and generically around possible issues, when dealing with an opaque object you do not define and control, to avoid creating issues with private fields or functions which may be part of the implementation, but not in whatever documented interface you are programming to. Not all the world is...C, POSIX, or Linux, compliant. -- 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

Minor (unimportant really) technical UB bug in strftime() ?
by Robert Elz Nov. 11, 2022

Nov. 11, 2022

The code for the %s strftime conversion starts as: (this taken from tzcode2022f strftime.c - but I suspect that many versions are the same) case 's': { struct tm tm; char buf[INT_STRLEN_MAXIMUM( time_t) + 1]; time_t mkt; tm = *t; mkt = mktime(&tm); The "tm = *t;" line is the problem. It (or more correctly, something to replace that) is needed, as *t is const, strftime() is not permitted to modify it, yet the struct tm * passed to mktime() is not const, as mktime is sometimes required to modify that struct before returning. However, mktime() refers only to the fields tm_year tm_mon tm_mday tm_hour tm_min tm_sec and tm_isdst of the struct passed to it. The %s conversion is defined as producing (in a decimal string format) the result of mktime() applied to the struct tm passed to strftime. Hence an application which intends to use strftime(..., "%s", ...) need only initialise those 7 fields, the other 2 (currently) standard fields (tm_yday and tm_wday) are explicitly ignored by mktime() on input, so there is no need to assign those values, and any other fields that might exist in a particular implementation are out of scope for a portable (conforming) application to touch, so cannot be initialised. Since referring to an uninitialised variable is, I believe, technically undefined behaviour, doing a struct copy (copying all fields) can have that effect. (An application could memset() the entire struct before providing the values it must add, but is not required to do that). It seems likely that the simple fix is to replace the struct assignment with 7 individual assignment statements tm.tm_year = t->tm_year; tm.tm_mon = t->tm_mon; /* ... */ On the other hand, hardware that balks at simply loading or copying, uninitialised values, without using them for any purpose is not exactly common (and half the world's code would probably break if an implementation that worked in such a manner was ever created) so I'd call this one of the less significant issues to worry about fixing. kre

10 26

End of time change in Colombia 1993
by Alois Treindl Nov. 10, 2022

Nov. 10, 2022

TZ has for Colombia a single period with time zone 4h west. # Rule NAME FROM TO - IN ON AT SAVE LETTER/S Rule CO 1992 only - May 3 0:00 1:00 - Rule CO 1993 only - Apr 4 0:00 0 - I think the end date 4 April is wrong, it should be 6 February 24h or 7 February 0h The time shift was called Hora Gaviria, and caused by shortage of electricity in connection with El Niño . Source: *DECRETO 267 DE 1993 * https://www.suin-juriscol.gov.co/viewDocument.asp?ruta=Decretos/1061335 *Artículo 1° *Adoptar como hora legal en el territorio de la República, la del Tiempo Universal Coordinado, UTC, disminuido en cinco (5) horas. *Artículo 2° *El cambio de hora se hará efectivo a las veinticuatro horas del día 6 de febrero del presente año. There is also a newspaper article https://www.eltiempo.com/archivo/documento/MAM-32922 of 4 feb 1993, but the text is less clear to my limited understanding of Spanish. See also https://es.wikipedia.org/wiki/Crisis_energ%C3%A9tica_de_1992_en_Colombia **

1 1

[PROPOSED] Support timegm by default, as per C23
by Paul Eggert Nov. 10, 2022

Nov. 10, 2022

Also, fix a bug in timegm; it sometimes modified its input even on failure. * Makefile, NEWS: Mention this. * localtime.c (mktmcpy): New static function. (time2sub): Use it. (timegm, timeoff): Define even if !STD_INSPIRED. (timeoff): Make it static if !STD_INSPIRED. (timegm): Do not modify *TMP on failure, even if only to change TMP->is_isdst. * private.h (HAVE_DECL_TIMEGM): Specify reasonable default value. (timegm): Always declare one way or another. --- Makefile | 8 +++----- NEWS | 5 +++++ localtime.c | 53 +++++++++++++++++++++++++++++++++-------------------- private.h | 18 +++++++++++++++--- 4 files changed, 56 insertions(+), 28 deletions(-) diff --git a/Makefile b/Makefile index 9ee15607..5ec0d4ab 100644 --- a/Makefile +++ b/Makefile @@ -209,6 +209,7 @@ LDLIBS= # For example, N is 252460800 on AmigaOS. # -DHAVE_DECL_ASCTIME_R=0 if <time.h> does not declare asctime_r # -DHAVE_DECL_ENVIRON if <unistd.h> declares 'environ' +# -DHAVE_DECL_TIMEGM=0 if <time.h> does not declare timegm # -DHAVE_DIRECT_H if mkdir needs <direct.h> (MS-Windows) # -DHAVE_GENERIC=0 if _Generic does not work* # -DHAVE_GETRANDOM if getrandom works (e.g., GNU/Linux), @@ -344,14 +345,11 @@ GCC_DEBUG_FLAGS = -DGCC_LINT -g3 -O3 -fno-common \ # If you want functions that were inspired by early versions of X3J11's work, # add # -DSTD_INSPIRED -# to the end of the "CFLAGS=" line. This arranges for the functions -# "offtime", "timelocal", "timegm", "timeoff", -# "posix2time", and "time2posix" to be added to the time conversion library. +# to the end of the "CFLAGS=" line. This arranges for the following +# functions to be added to the time conversion library. # "offtime" is like "gmtime" except that it accepts a second (long) argument # that gives an offset to add to the time_t when converting it. # "timelocal" is equivalent to "mktime". -# "timegm" is like "timelocal" except that it turns a struct tm into -# a time_t using UT (rather than local time as "timelocal" does). # "timeoff" is like "timegm" except that it accepts a second (long) argument # that gives an offset to use when converting to a time_t. # "posix2time" and "time2posix" are described in an included manual page. diff --git a/NEWS b/NEWS index 4a053077..23f1f7f1 100644 --- a/NEWS +++ b/NEWS @@ -2,6 +2,7 @@ News for the tz database Briefly: Fix some pre-1996 timestamps in northern Canada + C23 timegm now supported by default Unreleased, experimental changes @@ -22,6 +23,10 @@ Unreleased, experimental changes Changes to code + timegm, which tzcode implemented in 1989, will finally be + standardized 34 years later as part of C23, so timegm is now + supported even if STD_INSPIRED is not defined. + Fix bug in zdump's tzalloc emulation on hosts that lack tm_zone. (Problem reported by Đoàn Trần Công Danh.) diff --git a/localtime.c b/localtime.c index 712be135..9935b5d3 100644 --- a/localtime.c +++ b/localtime.c @@ -1951,6 +1951,23 @@ tmcomp(register const struct tm *const atmp, return result; } +/* Copy to *DEST from *SRC. Copy only the members needed for mktime, + as other members might not be initialized. */ +static void +mktmcpy(struct tm *dest, struct tm *const src) +{ + dest->tm_sec = src->tm_sec; + dest->tm_min = src->tm_min; + dest->tm_hour = src->tm_hour; + dest->tm_mday = src->tm_mday; + dest->tm_mon = src->tm_mon; + dest->tm_year = src->tm_year; + dest->tm_isdst = src->tm_isdst; +#if defined TM_GMTOFF && ! UNINIT_TRAP + dest->TM_GMTOFF = src->TM_GMTOFF; +#endif +} + static time_t time2sub(struct tm *const tmp, struct tm *(*funcp)(struct state const *, time_t const *, @@ -1972,17 +1989,7 @@ time2sub(struct tm *const tmp, struct tm yourtm, mytm; *okayp = false; - - yourtm.tm_sec = tmp->tm_sec; - yourtm.tm_min = tmp->tm_min; - yourtm.tm_hour = tmp->tm_hour; - yourtm.tm_mday = tmp->tm_mday; - yourtm.tm_mon = tmp->tm_mon; - yourtm.tm_year = tmp->tm_year; - yourtm.tm_isdst = tmp->tm_isdst; -#if defined TM_GMTOFF && ! UNINIT_TRAP - yourtm.TM_GMTOFF = tmp->TM_GMTOFF; -#endif + mktmcpy(&yourtm, tmp); if (do_norm_secs) { if (normalize_overflow(&yourtm.tm_min, &yourtm.tm_sec, @@ -2289,7 +2296,6 @@ mktime(struct tm *tmp) } #ifdef STD_INSPIRED - time_t timelocal(struct tm *tmp) { @@ -2297,13 +2303,9 @@ timelocal(struct tm *tmp) tmp->tm_isdst = -1; /* in case it wasn't initialized */ return mktime(tmp); } - -time_t -timegm(struct tm *tmp) -{ - return timeoff(tmp, 0); -} - +#else +static +#endif time_t timeoff(struct tm *tmp, long offset) { @@ -2313,7 +2315,18 @@ timeoff(struct tm *tmp, long offset) return time1(tmp, gmtsub, gmtptr, offset); } -#endif /* defined STD_INSPIRED */ +time_t +timegm(struct tm *tmp) +{ + time_t t; + struct tm tmcpy; + mktmcpy(&tmcpy, tmp); + tmcpy.tm_wday = -1; + t = timeoff(&tmcpy, 0); + if (0 <= tmcpy.tm_wday) + *tmp = tmcpy; + return t; +} static int_fast32_t leapcorr(struct state const *sp, time_t t) diff --git a/private.h b/private.h index 7cbd56d2..7320173f 100644 --- a/private.h +++ b/private.h @@ -543,9 +543,24 @@ struct tm *localtime(time_t const *); struct tm *localtime_r(time_t const *restrict, struct tm *restrict); time_t mktime(struct tm *); time_t time(time_t *); +time_t timegm(struct tm *); void tzset(void); #endif +#ifndef HAVE_DECL_TIMEGM +# if (202311 <= __STDC_VERSION__ \ + || defined __GLIBC__ || defined __tm_zone /* musl */ \ + || defined __FreeBSD__ || defined __NetBSD__ || defined __OpenBSD__ \ + || (defined __APPLE__ && defined __MACH__)) +# define HAVE_DECL_TIMEGM true +# else +# define HAVE_DECL_TIMEGM false +# endif +#endif +#if !HAVE_DECL_TIMEGM && !defined timegm +time_t timegm(struct tm *); +#endif + #if !HAVE_DECL_ASCTIME_R && !defined asctime_r extern char *asctime_r(struct tm const *restrict, char *restrict); #endif @@ -582,9 +597,6 @@ extern long altzone; # if TZ_TIME_T || !defined offtime struct tm *offtime(time_t const *, long); # endif -# if TZ_TIME_T || !defined timegm -time_t timegm(struct tm *); -# endif # if TZ_TIME_T || !defined timelocal time_t timelocal(struct tm *); # endif -- 2.37.2

1 0

No Daylight Savings in Fiji For year 2022-2023
by Jashneel Kumar Nov. 9, 2022

Nov. 9, 2022

Dear Timezone Support, I would like to inform you that there will be no Daylight Saving in Fiji this year. Can you please check that the same is reflected in the time zone database. Regards, [New_VF_Icon_RGB_RED] Jashneel Kumar Manager Data Networks & Services Jashneel.Kumar(a)vodafone.com.fj<mailto:Jashneel.Kumar@vodafone.com.fj> Vodafone Fiji PTE Limited, 168 Princes Rd, Tamavua, Suva, Fiji Islands www.vodafone.com.fj<http://www.vodafone.com.fj/> Together we can [Vodafone] ________________________________ The content of this email including any attachments is confidential and may contain information that is proprietary and privileged. If you are not the intended recipient be advised that you have received this email in error and that any use, dissemination, forwarding, printing or copying of this email is strictly prohibited. If you have received this email in error please notify E-mail Administrator on info(a)vodafone.com.fj Please also destroy and delete this message from your system. Vodafone Fiji PTE Limited does not guarantee that this message is free from computer virus or any other defect. The reader accepts full responsibility for taking defensive and counteractive action needed to rectify the computer virus or other defects caused. Vodafone Fiji PTE Limited : Private Mail Bag, Suva, Fiji | Telephone : +679 3312000 | E-Mail : info(a)vodafone.com.fj Please consider your environmental responsibility before printing this e-mail [https://www.vodafone.com.fj//images/default-source/logo/logo-2x.png] Vodafone Fiji PTE Ltd <https://www.vodafone.com.fj/>

3 5

Yukon, NWT, and Nunavut (Canada)
by Chris Walton Nov. 7, 2022

Nov. 7, 2022

There are some inaccuracies in the TZ database rules for Northern Canada between the years 1965 and 1995. ---------------------------------------------------------------------------------------- *Item A: On Sunday April 25, 1965, all parts of the Yukon switched to Yukon Double Daylight Time (YDDT). * This event is recorded in the database, but the associated rules have been incorrectly extended to cover almost all of Northern Canada. News article 1: *Whitehorse Star *—* Thursday April 22, 1965 *—* page 1* title: *DST Starts Monday* > > Yukon Daylight Saving Time starts this weekend. Clocks will be turned > ahead two hours after midnight Saturday, April 24 and there may be a lot of > people late for church this Sunday. > Trial period for DST was approved by Territorial Council last month for > this summer, after which a second look may be taken from Yukoners' point of > view. Two hour change was adopted to fall in line with British Columbia > and Alberta summer times. https://www.newspapers.com/image/578587481/ The title of this first article is wrong and/or misleading. Also, the start time shown in the article is vague; it simply says "after midnight" when it probably should have stated 2:00a.m. News article 2: *Whitehorse Star *—* Thursday April 29, 1965 *—* page 1* title: *DST Continues 'Till Hallowe'en* > Daylight Saving Time started in the Yukon five days ago, and already the > Commissioner's office is being besieged with calls from sleepy local > citizens wanting to know when it's going to end. > The two-hour change which began Sunday at two a.m. brings the Territory > into line with B.C. and Alberta time for the summer, but three hours ahead > for travelers from Alaska. > An official said Wednesday that many calls have come in from people asking > how long the experiment will last. The answer is another six months. > Date for the change back to Yukon Standard Time Oct. 31 at two a.m. https://www.newspapers.com/image/578588221/ News article 3: *Whitehorse Star *—* Monday October 25, 1965 *—* page 15* > Commissioner G.C. Cameron announced today that daylight Saving Time will > come to an end, for this year, at 2a.m. October 31. This means that all > clocks and watches should be turned back two hours as of that date. > The double daylight saving time was adopted this summer, on a trial basis > , so that Yukon time would correspondent with British Columbia and Alberta > time. > ... https://www.newspapers.com/image/578589147/ The 1965 Yukon Council minutes can be found here: http://assets.yukonarchives.ca/PER_YG_06_1965_C20_S02_v1.pdf Unfortunately I could not find an official CO or OIC. It is clear from the council minutes and the newspaper articles that the Yukon government wanted the clocks to be in sync with British Columbia and Alberta for the summer. However, the Yukon council members never once mentioned NWT (Northwest Territories) when debating or discussing the time change. I do not currently believe that NWT touched any of its clocks in 1965. Keep in mind that the land currently under the jurisdiction of Nunavut belonged to NWT prior to 1999. *All of the 1965 clock transitions for NWT and Nunavut should be removed from the TZ database unless somebody can provide compelling evidence to support them.* Zones in need of fixing: America/Yellowknife (NWT) America/Inuvik (NWT) America/Iqaluit (Nunavut) America/Cambridge_Bay (Nunavut) America/Pangnirtung (Nunavut) America/Rankin_Inlet (Nunavut) America/Resolute (Nunavut) *For the two Yukon zones, the April 25, 1965 start time should probably be changed in the TZ database from 00:00 to 2:00am.* Zones in need of fixing: America/Whitehorse America/Dawson ---------------------------------------------------------------------------------------- *Item B: On Sunday February 27, 1966, the part of the Yukon that lies east of the 136th meridian and south of the 62nd parallel switched from UTC-9 to UTC-8.* This change was mandated by Commissioner's Order 1966-20. Brian Inglis referenced it in a 2015 posting to this mailing list. https://mm.icann.org/pipermail/tz/2015-April/022200.html Brian was unable to locate a copy of the Commissioner's Order or any details about it. He simply stated "no online source found". I found two newspaper articles which give us the missing details: News article 1: *Whitehorse Star *—* Thursday Feb 24,1966 *—* page 2* title: *It's Time for YDT* > Sometime between midnight Saturday, Feb. 26 and Sunday morning Feb. 27, > residents of the southern part of the Yukon will get a bonus of an extra > hour for Rendezvous celebrating. > That's the date for changeover to Yukon Daylight Time which resulted from > the recent territorial plebiscite on the subject. > From Whitehorse to Watson Lake, settlements will observe the fast time; > elsewhere, Yukoners will remain on Yukon Standard Time. > Whitehorse, Ross River, Carcross, Teslin, Brooks Brook, Johnson's > Crossing, Watson Lake and Upper Liard... when the clock is wound at > midnight this Saturday, the hands should be set ahead one hour... to one > o'clock Yukon Daylight Time. https://www.newspapers.com/image/578575979/ I don't think that the author understood that moving the clock forward meant an hour was lost instead of gained! Oh well! Also, it was a permanent change and should not have been considered to be "daylight time". News article 2 (with more detail): *Whitehorse Star *—* Thursday March 3, 1966 *—* page 15* title: *Standard Time for Election* > Returning Officer R. B. COUSINS Wednesday received a reply from Chief > Electoral Officer N. Castonguay, in Ottawa, ruling on the matter of time > changes in Yukon affecting the territorial by-election in Whitehorse West > next Monday. His Message read as follows: > "Commissioner's Order 1966-20, dated January 27, 1966, provides from and > after midnight February 26, Yukon Standard Time as defined by section 36 of > the Interpretation Ordinance shall be reckoned in the same manner as > Pacific Standard Time. That is eight hours behind Greenwich Mean Time for > the area lying east of 136 degrees longitude and west and south of 62 > degrees latitude. In the remainder of the territory Yukon standard time > shall be reckoned as nine hours behind Greenwich mean time. This means > that in Whitehorse, Yukon Standard Time is eight hours behind Greenwich > Mean Time and all operations of Canada Elections Act in your electoral > district are governed by Yukon Standard Time. Advise all candidates and > other parties interested." > In other words, Yukon time in Whitehorse Monday for purposes of voting > will be the same as anything else... Yukon Southern Standard. https://www.newspapers.com/image/578577076/ There is a typo in this article where it says "and west and south". It presumably should have stated "lying east of 136° West longitude and south of 62° North latitude". *This change is not currently reflected in the TZ database; it should be applied to America/Whitehorse as a permanent change from UTC-9(YST) to UTC-8(PST) at 00:00 on Sunday February 27, 1966.* Zones in need of fixing: America/Whitehorse ---------------------------------------------------------------------------------------- *Item C: On Sunday May 28, 1967, the Yukon redefined the boundary between UTC-9 and UTC-8 to be a single straight line running along the 138th Meridian.* This change was a result of Commissioner's Order 1967-59 which can be seen at https://articles.adsabs.harvard.edu//full/1970JRASC..64..129T/0000156.000.h… page 156. Brian Inglis already quoted the Commissioner's Order on this mailing list (in the same posting I mentioned for item B above), but I will provide it again here. > COMMISSIONER'S ORDER 1967-59: > 1. Commissioner's Order 1966-20 dated at Whitehorse in the Yukon > Territory on 27th January, 1966, is hereby revoked. > 2. Yukon (East) Standard Time as defined by section 36 of the > Interpretation Ordinance from and after mid-night on the 28th day of May, > 1967 shall be reckoned in the same manner as Pacific Standard Time, that is > to say, eight hours behind Greenwich Time in the area of the Yukon > Territory lying east of the 138th degree longitude west. > 3. In the remainder of the Territory, lying west of the 138th degree > longitude west, Yukon (West) Standard Time shall be reckoned as nine hours > behind Greenwich Time. News article: *Whitehorse Star *—* Thursday May 11, 1967 *—* page 1* title: *Don't Touch That Clock* > The Yukon will be going on a new double time system after midnight May 28 > but Whitehorse residents won't notice the change. > Neither will most of the residents in other Yukon communities. > The change will place everyone on the east side of the 138 meridian on > Pacific Standard Time which is the same as Yukon Southern Standard Time > which is the same as Yukon Eastern Standard Time which is what most of > these people are on now. > Everyone on the west side of the 138th meridian will be on Yukon Standard > Time, or nine hours behind Greenwich time, which is Yukon Northern Standard > Time which is Yukon Western Standard Time, which is what they're on now. > The meridian runs north and south through the territory, passing near > Gravel Lake on the Stewart-Dawson Road, and just past Haines Junction on > the Alaska Highway. > This means that residents of Haines Junction, who petitioned for the > change several months ago, will now be on the same time as Whitehorse, > moving their clocks ahead one hour at midnight May 28. The same applies to > Carmacks residents, and some in Mayo and Keno. > Elsa adopted Whitehorse time for practical business reasons some time ago. > Announcing the forthcoming change to Territorial Council this week, > Commissioner J. Smith said the new system will be tried for a year and if > it doesn't work out, the entire territory will revert to one time zone > again. https://www.newspapers.com/image/578592950/ The Commissioner's Order and the newspaper article both refer to "midnight" on May 28. This possibly should be interpreted as "00:00 Sunday May 28" instead of "24:00 Sunday May 28" because a scheduled change for a Sunday night seems unlikely. However, the exact time and date is moot for the purposes of the TZ database because the change did not affect either Dawson City or Whitehorse. If it were not for the 1970 cutoff policy in the TZ database, we would need a new zone named "America/Carmacks" or "America/Haines_Junction"... and only then would we need to worry about the exact date and time of the transition. It seems like we might also have needed "America/Elsa". *The TZ database currently shows America/Whitehorse changing from UTC-9 to UTC-8 at 00:00 May 28, 1967; this rule is incorrect because Whitehorse had already transitioned to UTC-8 the year before. See item (B) above.* Zones in need of fixing: America/Whitehorse ---------------------------------------------------------------------------------------- *Item D: The Northwest Territories has been using daylight saving every summer since 1972.* News article 1: *Whitehorse Star *—* Friday April 28,1972 *—* page 6* title: *Daylight Saving Time for N.W.T.* > The Northwest Territories goes on daylight saving time at 2 a.m. on Sunday > when residents will set their clocks ahead one hour. > The only exception is the community of Coral Harbour on Southampton Island > which will remain unchanged in order that residents there will be on the > same time as those in the Keewatin. > Coral Harbour is in the eastern time zone and is one hour ahead of the > Keewatin region which operates in the central time zone. > Daylight saving time in the Territories is necessary to eliminate the > confusion in work hours between northern and southern Canada. > The move is being made because Alberta will be going on daylight saving > time for the first time on a province-wide basis at the same time. > If the NWT did not follow suit, all Alberta communities would be one hour > ahead of communities in the Mackenzie District of the NWT causing > difficulties and confusion in respect to transportation scheduling and > radio programming https://www.newspapers.com/image/578701610/ <https://www.newspapers.com/image/578701610/> The implication is that NWT started using daylight saving at 2:00a.m. on Sunday April 30,1972 which matches the records we have for Alberta. Note: there is a blog about this at https://cabinradio.ca/91751/news/remembering-the-start-of-daylight-saving-i… The blog has an image of the same newspaper article; it claims the article was published on April 18 instead of April 28 but that is an error. Another bit of proof that NWT (and much of Canada) was already using daylight saving prior to 1980 lies in the wording of the following Yukon article: *Whitehorse Star *—* Friday April 25,1980 *—* page 1* title: *Turn Your Clock Ahead Sunday* > As of 2 a.m next Sunday, Yukoners will become the last people across > Canada to join the ranks of the enlightened — on daylight saving time. > Clocks will be turned ahead one hour. That means on Sunday morning, what > was 7:00 last week will then be 8:00. Standard time resumes next October. > So you'll get one less hour's sleep tomorrow night. Daylight saving is > said to save on energy and even reduce crime. But don't lose any sleep over > it. https://www.newspapers.com/image/578597701/ Obviously I would have preferred to cite a Yellowknife (NWT) newspaper instead of a Whitehorse (Yukon) newspaper, but I could not find online archives of Yellowknife newspapers for the applicable time frame. *Nunavut and NWT zones should be updated in the TZ database to show observance of DST starting in 1972 instead of 1980.Start and End dates should be the same as the rest of Canada (last Sunday in April to last Sunday in October) with all transitions at 2:00a.m.* Zones in need of fixing: America/Yellowknife (NWT) America/Inuvik (NWT) America/Iqaluit (Nunavut) America/Cambridge_Bay (Nunavut) America/Pangnirtung (Nunavut) America/Rankin_Inlet (Nunavut) America/Resolute (Nunavut) Note that no changes are required for the two Yukon zones that correctly show Yukon reinstating daylight saving in 1980. ---------------------------------------------------------------------------------------- *Item E: Pangnirtung* A comment in the TZ database northamerica file reads: "Pangnirtung switched to eastern time; we'll guess 1995." Context: The communities of Pangnirtung and Qikiqtarjuaq (Broughton Island) are located on the east side of Baffin Island in Nunavut; they sit east of 68°W and according to the old NWT legislation, they were both supposed to have been on Atlantic Time. The 5th edition of the Atlas of Canada contains a time zone map that shows both legislated and observed time zone boundaries. All communities on Baffin Island are shown to be *observing *Eastern time. The date on the map is 1984. https://ftp.maps.canada.ca/pub/nrcan_rncan/raster/atlas_5_ed/eng/other/ referencemaps/mcr4056.pdf The implication is that Pangnirtung and Qikiqtarjuaq have observed Eastern Time as far back as 1984 (and likely even further back than that). It is possible that these communities never actually observed Atlantic Time, but that would be difficult to prove. *The TZ database rules for America/Pangirtung should be adjusted to show Eastern Time as far back as at least 1984.* Theoretically the zone could also be moved to the backzone file due to lack of any reliable history between 1970 and 1984; but I am not going to actively push for that. Zones in need of fixing: America/Pangnirtung (Nunavut) FYI: There is an older time zone map in the 4th edition of the Atlas of Canada. It has a date of 1967. Unfortunately it shows only the legislated boundaries which are not useful to us. https://ftp.maps.canada.ca/pub/nrcan_rncan/raster/atlas_4_ed/eng/economic/ transportationandcommunications/225_226.pdf ---------------------------------------------------------------------------------------- -chris

2 2

Bug in 2022f version of zic.c
by Tim McBrayer Nov. 7, 2022

Nov. 7, 2022

Hi, tzcode2022f/zic.c has a bug in its memory checker routine in static void* memcheck(void*). This code throws an error and exits when the pointer returned by malloc is NULL. However, malloc is allowed to return a NULL pointer when the allocation size is 0. And, on one machine I am building the TZ code on, malloc(0) does indeed return NULL. This is an AIX 6.1 box, with C compiler xlC 13.01.0000.0011. This is easy enough to work around locally. However, it would be nice to get this fixed for any future release of the TZ code. --- Tim McBrayer Ab Initio Software NOTICE from Ab Initio: This email (including any attachments) may contain information that is subject to confidentiality obligations or is legally privileged, and sender does not waive confidentiality or privilege. If received in error, please notify the sender, delete this email, and make no further use, disclosure, or distribution.

4 4

[PROPOSED] Generate nicer 'make check' output
by Paul Eggert Nov. 6, 2022

Nov. 6, 2022

* Makefile (DIFF_TZS): New macro. (check_tzs, $(TIME_T_ALTERNATIVES)): Use it. --- Makefile | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/Makefile b/Makefile index 8c4c6aba..9ee15607 100644 --- a/Makefile +++ b/Makefile @@ -499,6 +499,11 @@ TARFLAGS= `if tar $(GNUTARFLAGS) --version >/dev/null 2>&1; \ # Flags to give 'gzip' when making a distribution. GZIPFLAGS= -9n +# When comparing .tzs files, use GNU diff's -F'^TZ=' option if supported. +# This makes it easier to see which Zone has been affected. +DIFF_TZS= diff -u$$(! diff -u -F'^TZ=' - - <>/dev/null >&0 2>&1 \ + || echo ' -F^TZ=') + ############################################################################### #MAKE= make @@ -857,7 +862,7 @@ check_tables: checktab.awk $(YDATA) backward $(ZONETABLES) check_tzs: $(TZS) $(TZS_NEW) if test -s $(TZS); then \ - diff -u $(TZS) $(TZS_NEW); \ + $(DIFF_TZS) $(TZS) $(TZS_NEW); \ else \ cp $(TZS_NEW) $(TZS); \ fi @@ -1058,7 +1063,7 @@ $(TIME_T_ALTERNATIVES): $(VERSION_DEPS) TZS_YEAR="$$range" TZS_CUTOFF_FLAG="-t $$range" \ D=$$wd/$@.dir \ to$$range.tzs) && \ - diff -u $(TIME_T_ALTERNATIVES_HEAD).dir/to$$range.tzs \ + $(DIFF_TZS) $(TIME_T_ALTERNATIVES_HEAD).dir/to$$range.tzs \ $@.dir/to$$range.tzs && \ if diff -q Makefile Makefile 2>/dev/null; then \ quiet_option='-q'; \ -- 2.37.2

1 0

[PROPOSED] Fix unlikely conversion bug in zic
by Paul Eggert Nov. 5, 2022

Nov. 5, 2022

* zic.c (puttzcode): Arg is zic_t, not int_fast32_t. This fixes a portability bug on platforms where int_fast32_t is a 32-bit ones’ complement or signed-magnitude integer, and where the argument is -2**31 before conversion to int_fast32_t. Although I don’t know of any such platforms, the C standard allows them. --- zic.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/zic.c b/zic.c index d8bdbb96..548c1c5f 100644 --- a/zic.c +++ b/zic.c @@ -2216,7 +2216,7 @@ convert64(uint_fast64_t val, char *buf) } static void -puttzcode(const int_fast32_t val, FILE *const fp) +puttzcode(zic_t val, FILE *fp) { char buf[4]; -- 2.37.2

2 1