- tz - lists.iana.org

[PROPOSED] SUPPORT_C89 now defaults to 1, not 0
by Paul Eggert June 8, 2024

June 8, 2024

Although POSIX requires this, I didn’t notice it until today. * Makefile, NEWS, localtime.c: Mention this. * private.h (SUPPORT_C89): Default to 1, not 0. --- Makefile | 5 +++-- NEWS | 4 ++++ localtime.c | 5 +++-- private.h | 17 ++++++++++------- 4 files changed, 20 insertions(+), 11 deletions(-) diff --git a/Makefile b/Makefile index 97a88535..c00eb317 100644 --- a/Makefile +++ b/Makefile @@ -263,8 +263,9 @@ LDLIBS= # -DRESERVE_STD_EXT_IDS if your platform reserves standard identifiers # with external linkage, e.g., applications cannot define 'localtime'. # -Dssize_t=long on hosts like MS-Windows that lack ssize_t -# -DSUPPORT_C89 if the tzcode library should support C89 callers+ -# However, this might trigger latent bugs in C99-or-later callers. +# -DSUPPORT_C89=0 if the tzcode library should not support C89 callers +# Although -DSUPPORT_C89=0 might work around latent bugs in callers, +# it does not conform to POSIX. # -DSUPPORT_POSIX2008 if the library should support older POSIX callers+ # However, this might cause problems in POSIX.1-2024-or-later callers. # -DSUPPRESS_TZDIR to not prepend TZDIR to file names; this has diff --git a/NEWS b/NEWS index 6b71212c..5238cb9e 100644 --- a/NEWS +++ b/NEWS @@ -8,6 +8,7 @@ Unreleased, experimental changes The code now conforms to RFC 8536 for early timestamps. Support POSIX.1-2024, which removes asctime_r and ctime_r. Assume POSIX.2-1992 or later for shell scripts. + SUPPORT_C89 now defaults to 1. Improve historical data for Portugal and possessions. Changes to data @@ -60,6 +61,9 @@ Unreleased, experimental changes can overrun user buffers. If you still need them, add -DSUPPORT_POSIX2008 to CFLAGS. + The SUPPORT_C89 option now defaults to 1 instead of 0, fixing a + POSIX-conformance bug introduced in 2023a. + tzselect now assumes POSIX.2-1992 or later, as practical porting targets now all support this. Also, tzselect uses some features from POSIX.1-2024 if available. diff --git a/localtime.c b/localtime.c index c9f0d1a8..7e3fd149 100644 --- a/localtime.c +++ b/localtime.c @@ -182,8 +182,9 @@ static int lcl_is_set; ** objects: a broken-down time structure and an array of char. ** Thanks to Paul Eggert for noting this. ** -** This requirement was removed in C99, so support it only if requested, -** as support is more likely to lead to bugs in badly written programs. +** Although this requirement was removed in C99 it is still present in POSIX. +** Follow the requirement if SUPPORT_C89, even though this is more likely to +** trigger latent bugs in programs. */ #if SUPPORT_C89 diff --git a/private.h b/private.h index 0c91a252..19d7f7d6 100644 --- a/private.h +++ b/private.h @@ -19,19 +19,22 @@ /* PORT_TO_C89 means the code should work even if the underlying compiler and library support only C89 plus C99's 'long long' - and perhaps a few other extensions to C89. SUPPORT_C89 means the - tzcode library should support C89 callers in addition to the usual - support for C99-and-later callers; however, C89 support can trigger - latent bugs in C99-and-later callers. These macros are obsolescent, - and the plan is to remove them along with any code needed only when - they are nonzero. A good time to do that might be in the year 2029 + and perhaps a few other extensions to C89. + + This macro is obsolescent, and the plan is to remove it along with + associated code. A good time to do that might be in the year 2029 because RHEL 7 (whose GCC defaults to C89) extended life cycle support (ELS) is scheduled to end on 2028-06-30. */ #ifndef PORT_TO_C89 # define PORT_TO_C89 0 #endif + +/* SUPPORT_C89 means the tzcode library should support C89 callers + in addition to the usual support for C99-and-later callers. + This defaults to 1 as POSIX requires, even though that can trigger + latent bugs in callers. */ #ifndef SUPPORT_C89 -# define SUPPORT_C89 0 +# define SUPPORT_C89 1 #endif #ifndef __STDC_VERSION__ -- 2.43.0

2 1

[PROPOSED 00/12] Assume POSIX.2-1992
by Paul Eggert June 1, 2024

June 1, 2024

For many years we have maintained code in tzselect and Makefile intended to port to older platforms that predate POSIX.2-1992. The only remaining such platform that is still supported by its supplier is Solaris 10 (2005), which has a shell and related tools that are still pre-POSIX by default, although POSIX variants are available. However, I recently discovered that Solaris 10’s own copy of tzselect now uses POSIX.2-1992 features and is based on the POSIX variants. Now that even Oracle has abandoned its pre-POSIX environment for TZDB, it’s time for us to follow suit. This series of patches updates the Makefile and tzselect shell script to assume POSIX.2-1992 or later. This simplifies maintenance and speeds up the code a bit. Paul Eggert (12): Assume POSIX.2 and eschew ‘expr’ Prefer $(CMD) to `CMD` in Makefile Prefer $PWD to $(pwd) in Makefile Avoid subshells when possible Assume POSIX.2 command substitution * tzselect.ksh: Assume POSIX.2 $PWD. * tzselect.ksh: Assume POSIX.2 awk. Avoid some subshells in tzselect Avoid an awk invocation via $'...' Use ‘export VAR=VAL’ syntax Avoid crash in Solaris 10 /usr/xpg4/bin/make Port ! to Solaris make .gitignore | 4 +- Makefile | 343 +++++++++++++++++++++++++-------------------------- NEWS | 9 ++ checknow.awk | 2 +- tzselect.ksh | 112 +++++++---------- workman.sh | 3 +- 6 files changed, 231 insertions(+), 242 deletions(-) -- 2.45.1

1 12

[PROPOSED] difftime isn’t pure either
by Paul Eggert May 28, 2024

May 28, 2024

See <https://sourceware.org/bugzilla/show_bug.cgi?id=31808#c1>. * private.h (difftime): No longer pure. --- private.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/private.h b/private.h index cacbe444..0c91a252 100644 --- a/private.h +++ b/private.h @@ -702,7 +702,7 @@ DEPRECATED_IN_C23 char *ctime(time_t const *); char *asctime_r(struct tm const *restrict, char *restrict); char *ctime_r(time_t const *, char *); #endif -ATTRIBUTE_PURE double difftime(time_t, time_t); +double difftime(time_t, time_t); size_t strftime(char *restrict, size_t, char const *restrict, struct tm const *restrict); # if HAVE_STRFTIME_L -- 2.45.1

1 0

Unicode CLDR supplemental/windowsZones.xml update? -Brooks Harris
by Brooks Harris May 28, 2024

May 28, 2024

Does someone know if the Unicode CLDR ../supplemental/windowsZones.xml has been updated? Following the best links I know to find: Unicode CLDR Overview https://cldr.unicode.org/index/downloads/cldr-45 Downloads https://cldr.unicode.org/index/downloads GitHub Tag https://raw.githubusercontent.com/RobThree/TimeZoneMapper/master/TimeZoneMa… This file says it corresponds with TzDb 2021a. Yet other notes say Windows zone were updated to TzDb 2024a: CLDR 45 Release Note https://cldr.unicode.org/index/downloads/cldr-45 Timezones Deprecating timezones that are no longer in zone.tab (America/Nipigon, ...) New Windows timezone mappings Was this file not actually updated or am I looking in the wrong place? Thanks, -Brooks

4 6

[PROPOSED 1/4] More updates to GCC_DEBUG_FLAGS for GCC 14
by Paul Eggert May 27, 2024

May 27, 2024

* Makefile (GCC_DEBUG_FLAGS): Omit -fno-common, as it is now the default. Omit -Wuninitialized as it’s implied by -Wall. Omit -Wno-address and -Wno-type-limits as they don’t seem to be needed with GCC 14. --- Makefile | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/Makefile b/Makefile index 6b093013..4d2ac1cf 100644 --- a/Makefile +++ b/Makefile @@ -313,7 +313,7 @@ GCC_INSTRUMENT = \ -fsanitize=undefined -fsanitize-address-use-after-scope \ -fsanitize-undefined-trap-on-error -fstack-protector # Omit -fanalyzer from GCC_DEBUG_FLAGS, as it makes GCC too slow. -GCC_DEBUG_FLAGS = -DGCC_LINT -g3 -O3 -fno-common \ +GCC_DEBUG_FLAGS = -DGCC_LINT -g3 -O3 \ $(GCC_INSTRUMENT) \ -Wall -Wextra \ -Walloc-size-larger-than=100000 -Warray-bounds=2 \ @@ -332,10 +332,9 @@ GCC_DEBUG_FLAGS = -DGCC_LINT -g3 -O3 -fno-common \ -Wsuggest-attribute=const -Wsuggest-attribute=format \ -Wsuggest-attribute=malloc \ -Wsuggest-attribute=noreturn -Wsuggest-attribute=pure \ - -Wtrampolines -Wundef -Wuninitialized -Wunused-macros -Wuse-after-free=3 \ + -Wtrampolines -Wundef -Wunused-macros -Wuse-after-free=3 \ -Wvariadic-macros -Wvla -Wwrite-strings \ - -Wno-address -Wno-format-nonliteral -Wno-sign-compare \ - -Wno-type-limits + -Wno-format-nonliteral -Wno-sign-compare # # 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), -- 2.43.0

2 5

Re: [tz] Unicode CLDR supplemental/windowsZones.xml update? -Brooks Harris
by Paul Eggert May 27, 2024

May 27, 2024

On 2024-05-26 12:44, Brooks Harris wrote: > Hi Pail, > On 2024-05-26 03:37 PM, Paul Eggert wrote: >> On 2024-05-26 12:30, Brooks Harris via tz wrote: >>> What is the best procedure to obtain the latest windowsZones.xml? >> >> https://github.com/unicode-org/cldr/blob/main/common/supplemental/windowsZo… > > This file is identical to the old one I have and does not reflect the > commits you referred me to. That's not a file, it's a bunch of info about the file. The info includes the file contents and a bunch of other stuff. If you just want the file, click the Raw button. >>> Is there a record of earlier versions? >> https://github.com/unicode-org/cldr/commits/main/common/supplemental/window… >> >> These are reachable from the earlier URL I emailed. > > Right, but no version of windowsZones.xml I can find has those commits > applied. ? Those changes are visible to me via that URL. Anyway, try clicking the "Raw" button. It should give you this URL: https://raw.githubusercontent.com/unicode-org/cldr/main/common/supplemental… and I see the changes there too.

4 7

[PROPOSED 1/4] Update GCC_DEBUG_FLAGS for GCC 14
by Paul Eggert May 25, 2024

May 25, 2024

* Makefile (GCC_DEBUG_FLAGS): Add -Wflex-array-member-not-at-end, -Wmissing-variable-declarations. --- Makefile | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/Makefile b/Makefile index 3f550b3f..a72fb2ea 100644 --- a/Makefile +++ b/Makefile @@ -315,10 +315,11 @@ GCC_DEBUG_FLAGS = -DGCC_LINT -g3 -O3 -fno-common \ -Walloc-size-larger-than=100000 -Warray-bounds=2 \ -Wbad-function-cast -Wbidi-chars=any,ucn -Wcast-align=strict -Wdate-time \ -Wdeclaration-after-statement -Wdouble-promotion \ - -Wduplicated-branches -Wduplicated-cond \ + -Wduplicated-branches -Wduplicated-cond -Wflex-array-member-not-at-end \ -Wformat=2 -Wformat-overflow=2 -Wformat-signedness -Wformat-truncation \ -Wimplicit-fallthrough=5 -Winit-self -Wlogical-op \ - -Wmissing-declarations -Wmissing-prototypes -Wnested-externs \ + -Wmissing-declarations -Wmissing-prototypes \ + -Wmissing-variable-declarations -Wnested-externs \ -Wnull-dereference \ -Wold-style-definition -Woverlength-strings -Wpointer-arith \ -Wshadow -Wshift-overflow=2 -Wstrict-overflow \ -- 2.45.1

1 3

[PROPOSED] Sub-second history for Maputo and Zurich
by Paul Eggert May 25, 2024

May 25, 2024

* africa (Africa/Maputo), europe (Europe/Zurich): Add #STDOFF comments for two zones with well-sourced standard time that was not an integral number of seconds away from UT. This does not change the TZif output files. --- africa | 5 +++-- europe | 5 +++-- 2 files changed, 6 insertions(+), 4 deletions(-) diff --git a/africa b/africa index 695d66ed..4f0d1e7b 100644 --- a/africa +++ b/africa @@ -1101,11 +1101,11 @@ Zone Africa/El_Aaiun -0:52:48 - LMT 1934 Jan # El Aaiún # Zambia # Zimbabwe # -# From Paul Eggert (2024-04-09): +# From Paul Eggert (2024-05-24): # The London Gazette, 1903-04-03, page 2245, says that # as of 1903-03-03 a time ball at the port of Lourenço Marques # (as Maputo was then called) was dropped daily at 13:00:00 LMT, -# corresponding to 22:49:41.7 GMT; round this to UT+2:10:18. +# corresponding to 22:49:41.7 GMT, so local time was +02:10:18.3. # Conversely, the newspaper South Africa, 1909-02-09, page 321, # says the port had just installed an apparatus that communicated # "from the controlling clock in the new Observatory at Reuben Point ... @@ -1116,6 +1116,7 @@ Zone Africa/El_Aaiun -0:52:48 - LMT 1934 Jan # El Aaiún # For lack of better info, list 1909 as the transition date. # # Zone NAME STDOFF RULES FORMAT [UNTIL] + #STDOFF 2:10:18.3 Zone Africa/Maputo 2:10:18 - LMT 1909 2:00 - CAT diff --git a/europe b/europe index 9ea14914..2f180e64 100644 --- a/europe +++ b/europe @@ -3486,8 +3486,8 @@ Zone Atlantic/Canary -1:01:36 - LMT 1922 Mar # Las Palmas de Gran C. # but if no one is present after 11 at night, could be postponed until one # hour before the beginning of service. -# From Paul Eggert (2013-09-11): -# Round BMT to the nearest even second, 0:29:46. +# From Paul Eggert (2024-05-24): +# Express BMT as 0:29:45.500, approximately the same precision 7° 26' 22.50". # # We can find no reliable source for Shanks's assertion that all of Switzerland # except Geneva switched to Bern Mean Time at 00:00 on 1848-09-12. This book: @@ -3526,6 +3526,7 @@ Rule Swiss 1941 1942 - May Mon>=1 1:00 1:00 S Rule Swiss 1941 1942 - Oct Mon>=1 2:00 0 - # Zone NAME STDOFF RULES FORMAT [UNTIL] Zone Europe/Zurich 0:34:08 - LMT 1853 Jul 16 # See above comment. + #STDOFF 0:29:45.500 0:29:46 - BMT 1894 Jun # Bern Mean Time 1:00 Swiss CE%sT 1981 1:00 EU CE%sT -- 2.43.0

2 2

Deprecating POSIX Zones to Links?
by Justin Grant May 23, 2024

May 23, 2024

Hi TZ friends - I'm one of the volunteers working on ECMAScript's time zone strategy. We had a question: of all the legacy Zone names in TZDB, why have a few of them like "WET" and "EST5EDT" been retained as Zones, while the rest of the legacy names like "GB-Eire" and "Jamaica" have all been turned into Links pointing to some other Zone? What was special about the Zones below that caused them to stay as Zones? EST MST HST EST5EDT CST6CDT MST7MDT PST8PDT WET CET MET EET Regardless of the history behind these 11 Zone names, would there be interest in accepting a PR that turns these Zones into Links? I'm asking because ECMAScript's time zone enumeration API is specified to only return Zone names, but ECMAScript implementations in Safari and Chrome have long omitted the Zones above from their enumeration API because they create redundant and confusing results for end users. We'd like to align the specification to web reality, and ideally make these changes upstream in TZDB (if that would be welcome). Here's the mappings that we're currently considering in ECMAScript. We used the TZ approach of preferring the largest city for each of the DST-using legacy Zones. Although any other mappings would be OK with us, so let me know if you think there are more appropriate mappings. EST => Etc/GMT+5 MST => Etc/GMT+7 HST => Etc/GMT+10 EST5EDT => America/New_York CST6CDT => America/Chicago MST7MDT => America/Denver PST8PDT => America/Los_Angeles WET => Europe/Lisbon CET => Europe/Berlin MET => Europe/Berlin EET => Europe/Kyiv Thanks, Justin Grant

3 7

[PROPOSED 1/2] Don’t be so sure about leap seconds going away
by Paul Eggert May 14, 2024

May 14, 2024

* NEWS, theory.html (Leap seconds): * tz-link.html (Precision timekeeping): Use less-sure wording about leap seconds discontinuance, since the situation is still murky. --- NEWS | 2 +- theory.html | 10 +++++----- tz-link.html | 1 + 3 files changed, 7 insertions(+), 6 deletions(-) diff --git a/NEWS b/NEWS index 5c2cd1e5..e5db26b4 100644 --- a/NEWS +++ b/NEWS @@ -322,7 +322,7 @@ Release 2023a - 2023-03-22 12:39:33 -0700 To improve tzselect diagnostics, zone1970.tab's comments column is now limited to countries that have multiple timezones. - Note that leap seconds are planned to be discontinued by 2035. + Note that there are plans to discontinue leap seconds by 2035. Release 2022g - 2022-11-29 08:58:31 -0800 diff --git a/theory.html b/theory.html index 50e9ee4d..4cb293da 100644 --- a/theory.html +++ b/theory.html @@ -1278,11 +1278,11 @@ between now and the future time. <p> Leap seconds were introduced in 1972 to accommodate the difference between atomic time and the less regular rotation of the earth. -Unfortunately they caused so many problems with civil -timekeeping that they -are <a href="https://www.bipm.org/en/cgpm-2022/resolution-4">planned -to be discontinued by 2035</a>. -Despite their impending obsolescence, a record of leap seconds is still +Unfortunately they have caused so many problems with civil +timekeeping that there are +<a href="https://www.bipm.org/en/cgpm-2022/resolution-4">plans +to discontinue them by 2035</a>. +Even if these plans come to fruition, a record of leap seconds will still be needed to resolve timestamps from 1972 through 2035. </p> diff --git a/tz-link.html b/tz-link.html index c6d96101..aaab7555 100644 --- a/tz-link.html +++ b/tz-link.html @@ -1129,6 +1129,7 @@ discontinuous adjustments be made to UTC for at least a century. The World Radiocommunication Conference <a href="https://www.itu.int/dms_pub/itu-r/opb/act/R-ACT-WRC.15-2023-PDF-E.pdf">resolved in 2023</a> to cooperate with this process. +However, there is still no consensus on how exactly to get rid of them. </li> </ul> </section> -- 2.40.1

1 1