- tz - lists.iana.org

Dead code in strftime()?
by Tom Lane Nov. 21, 2024

Nov. 21, 2024

strftime() in the 2024b tzcode distribution includes if (!p) { errno = EOVERFLOW; return 0; } AFAICS this is dead code, except maybe in the case that the call passes s = NULL, maxsize = 0, which doesn't seem like a case that the code intends to support (and EOVERFLOW would be a rather odd choice of error code if that's the idea). newstrftime.3.txt offers a clue about the intent: This function may fail if: [EOVERFLOW] The format includes an %s conversion and the number of seconds since the Epoch cannot be represented in a time_t. But the %s conversion code never returns zero. There's a suggestive comment there: /* If mktime fails, %s expands to the value of (time_t) -1 as a failure marker; this is better in practice than strftime failing. */ So it looks to me like somebody changed the error handling in the %s stanza but didn't bother to remove the now-dead path in the caller nor update the man page. Am I missing something? regards, tom lane

3 13

[PROPOSED 1/6] Improve zdump overflow checking
by Paul Eggert Nov. 21, 2024

Nov. 21, 2024

This also pacifies -Wsuggest-attribute=pure on x86 on platforms that lack tm_gmtoff and tm_zone. * zdump.c (xstrsize): Remove; no longer used. (tzalloc, saveabbr): Use plain strlen here, since the string sizes have already been checked. (main): Limit ‘longest’ to INT_MAX - 2 so that a printf with it and two spaces does not flake out. Check for arglen overflow once here, rather than on every alloc. --- zdump.c | 24 ++++++++---------------- 1 file changed, 8 insertions(+), 16 deletions(-) diff --git a/zdump.c b/zdump.c index e8178733..b668022d 100644 --- a/zdump.c +++ b/zdump.c @@ -148,17 +148,6 @@ sumsize(ptrdiff_t a, ptrdiff_t b) size_overflow(); } -/* Return the size of of the string STR, including its trailing NUL. - Report an error and exit if this would exceed INDEX_MAX which means - pointer subtraction wouldn't work. */ -static ptrdiff_t -xstrsize(char const *str) -{ - size_t len = strlen(str); - if (len < INDEX_MAX) - return len + 1; - size_overflow(); -} /* Return a pointer to a newly allocated buffer of size SIZE, exiting on failure. SIZE should be positive. */ @@ -266,7 +255,7 @@ tzalloc(char const *val) static ptrdiff_t fakeenv0size; void *freeable = NULL; char **env = fakeenv, **initial_environ; - ptrdiff_t valsize = xstrsize(val); + ptrdiff_t valsize = strlen(val) + 1; if (fakeenv0size < valsize) { char **e = environ, **to; ptrdiff_t initial_nenvptrs = 1; /* Counting the trailing NULL pointer. */ @@ -425,7 +414,7 @@ saveabbr(char **buf, ptrdiff_t *bufalloc, struct tm const *tmp) if (HAVE_LOCALTIME_RZ) return ab; else { - ptrdiff_t absize = xstrsize(ab); + ptrdiff_t absize = strlen(ab) + 1; if (*bufalloc < absize) { free(*buf); @@ -487,6 +476,7 @@ main(int argc, char *argv[]) register time_t cuthitime; time_t now; bool iflag = false; + size_t arglenmax = 0; cutlotime = absolute_min_time; cuthitime = absolute_max_time; @@ -586,12 +576,14 @@ main(int argc, char *argv[]) now = time(NULL); now |= !now; } - longest = 0; for (i = optind; i < argc; i++) { size_t arglen = strlen(argv[i]); - if (longest < arglen) - longest = min(arglen, INT_MAX); + if (arglenmax < arglen) + arglenmax = arglen; } + if (!HAVE_SETENV && INDEX_MAX <= arglenmax) + size_overflow(); + longest = min(arglenmax, INT_MAX - 2); for (i = optind; i < argc; ++i) { timezone_t tz = tzalloc(argv[i]); -- 2.47.0

1 5

(no subject)
by Cool Gab19 Nov. 7, 2024

Nov. 7, 2024

can you add Philippine Daylight Time on your Database I think it was missing from the list of the time zones please reply immediately if solved thanks...

4 8

[PROPOSED] * NEWS, europe: Belated thanks for Ittoqqortoormiit 2024 fix
by Paul Eggert Nov. 7, 2024

Nov. 7, 2024

--- NEWS | 2 +- europe | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/NEWS b/NEWS index a109ae9d..8381a197 100644 --- a/NEWS +++ b/NEWS @@ -233,7 +233,7 @@ Release 2023d - 2023-12-21 20:02:24 -0800 changing its time zone from -01/+00 to -02/-01 at the same moment as the spring-forward transition. Its clocks will therefore not spring forward as previously scheduled. The time zone change - reverts to its common practice before 1981. + reverts to its common practice before 1981. (Thanks to Jule Dabars.) Fix predictions for DST transitions in Palestine in 2072-2075, correcting a typo introduced in 2023a. (Thanks to Jule Dabars.) diff --git a/europe b/europe index f9063949..df334fc2 100644 --- a/europe +++ b/europe @@ -1147,7 +1147,7 @@ Zone Atlantic/Faroe -0:27:04 - LMT 1908 Jan 11 # Tórshavn # However, Greenland will change to Daylight Saving Time again in 2024 # and onwards. -# From a contributor who wishes to remain anonymous for now (2023-10-29): +# From Jule Dabars (2023-10-29): # https://www.dr.dk/nyheder/seneste/i-nat-skal-uret-stilles-en-time-tilbage-m… # with a link to that page: # https://naalakkersuisut.gl/Nyheder/2023/10/2710_sommertid -- 2.43.0

1 0

[PROPOSED] * NEWS: Belated thanks for Palestine 2072-2075 fix
by Paul Eggert Nov. 7, 2024

Nov. 7, 2024

--- NEWS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/NEWS b/NEWS index 8c315643..a109ae9d 100644 --- a/NEWS +++ b/NEWS @@ -236,7 +236,7 @@ Release 2023d - 2023-12-21 20:02:24 -0800 reverts to its common practice before 1981. Fix predictions for DST transitions in Palestine in 2072-2075, - correcting a typo introduced in 2023a. + correcting a typo introduced in 2023a. (Thanks to Jule Dabars.) Changes to past and future timestamps -- 2.43.0

1 0

[PATCH 1/2] Switch from RFC 8536 to 9636 for documentation
by Paul Eggert Nov. 3, 2024

Nov. 3, 2024

RFC 9636 is now published, and it obsoletes RFC 8536 for the Time Zone information format (TZif). --- Makefile | 2 +- NEWS | 4 ++++ localtime.c | 2 +- theory.html | 4 ++-- tz-link.html | 4 ++-- tzfile.5 | 12 ++++++------ tzfile.h | 2 +- zic.c | 4 ++-- 8 files changed, 19 insertions(+), 15 deletions(-) diff --git a/Makefile b/Makefile index 57d1d672..6e623eb0 100644 --- a/Makefile +++ b/Makefile @@ -137,7 +137,7 @@ TIME_T_ALTERNATIVES_TAIL = int_least32_t.ck uint_least32_t.ck \ uint_least64_t.ck # What kind of TZif data files to generate. (TZif is the binary time -# zone data format that zic generates; see Internet RFC 8536.) +# zone data format that zic generates; see Internet RFC 9636.) # If you want only POSIX time, with time values interpreted as # seconds since the epoch (not counting leap seconds), use # REDO= posix_only diff --git a/NEWS b/NEWS index adaa4b60..8c315643 100644 --- a/NEWS +++ b/NEWS @@ -24,6 +24,10 @@ Unreleased, experimental changes 1977, and May and July 1990; and removing incorrect transitions in March and September 1978. + Changes to documentation + + Cite Internet RFC 9636, which obsoletes RFC 8536 for TZif format. + Release 2024b - 2024-09-04 12:27:47 -0700 diff --git a/localtime.c b/localtime.c index 7ae9ce5e..f331473e 100644 --- a/localtime.c +++ b/localtime.c @@ -583,7 +583,7 @@ tzloadbody(char const *name, struct state *sp, bool doextend, correction must differ from the previous one's by 1 second or less, except that the first correction can be any value; these requirements are more generous than - RFC 8536, to allow future RFC extensions. */ + RFC 9636, to allow future RFC extensions. */ if (! (i == 0 || (prevcorr < corr ? corr == prevcorr + 1 diff --git a/theory.html b/theory.html index b1717e7d..4d72ee2e 100644 --- a/theory.html +++ b/theory.html @@ -1115,8 +1115,8 @@ However POSIX.1-2024, like earlier POSIX editions, has some limitations: the name of a file from which time-related information is read. The file's format is <dfn><abbr>TZif</abbr></dfn>, a timezone information format that contains binary data; see - <a href="https://datatracker.ietf.org/doc/html/8536">Internet - <abbr>RFC</abbr> 8536</a>. + <a href="https://datatracker.ietf.org/doc/html/9636">Internet + <abbr>RFC</abbr> 9636</a>. The daylight saving time rules to be used for a particular timezone are encoded in the <abbr>TZif</abbr> file; the format of the file allows <abbr>US</abbr>, diff --git a/tz-link.html b/tz-link.html index be2aae54..0853bd7d 100644 --- a/tz-link.html +++ b/tz-link.html @@ -194,9 +194,9 @@ After obtaining the code and data files, see the The code lets you compile the <code><abbr>tz</abbr></code> source files into machine-readable binary files, one for each location. The binary files are in a special format specified by -<a href="https://datatracker.ietf.org/doc/html/8536">The +<a href="https://datatracker.ietf.org/doc/html/9636">The Time Zone Information Format (<abbr>TZif</abbr>)</a> -(Internet <abbr title="Request For Comments">RFC</abbr> 8536). +(Internet <abbr title="Request For Comments">RFC</abbr> 9636). The code also lets you read a <abbr>TZif</abbr> file and interpret timestamps for that location.</p> diff --git a/tzfile.5 b/tzfile.5 index f2529b01..b699bd26 100644 --- a/tzfile.5 +++ b/tzfile.5 @@ -17,7 +17,7 @@ The timezone information files used by .BR tzset (3) are typically found under a directory with a name like .IR /usr/share/zoneinfo . -These files use the format described in Internet RFC 8536. +These files use the format described in Internet RFC 9636. Each file is a sequence of 8-bit bytes. In a file, a binary integer is represented by a sequence of one or more bytes in network order (bigendian, or high-order byte first), @@ -380,7 +380,7 @@ for permanent Atlantic Standard Time (\-04). .IP \(bu Some readers designed for version 2 or 3 and that require strict -conformance to RFC 8536 reject version 4 files whose leap second +conformance to RFC 9636 reject version 4 files whose leap second tables are truncated at the start or end in expiration times. .IP \(bu Some readers ignore the footer, and instead predict future @@ -514,9 +514,9 @@ of one hour, or of 15 minutes, or of 1 minute. .PP Olson A, Eggert P, Murchison K. The Time Zone Information Format (TZif). 2019 Feb. -.UR https://\:datatracker.ietf.org/\:doc/\:html/\:rfc8536 -Internet RFC 8536 +.UR https://\:datatracker.ietf.org/\:doc/\:html/\:rfc9636 +Internet RFC 9636 .UE -.UR https://\:doi.org/\:10.17487/\:RFC8536 -doi:10.17487/RFC8536 +.UR https://\:doi.org/\:10.17487/\:RFC9636 +doi:10.17487/RFC9636 .UE . diff --git a/tzfile.h b/tzfile.h index b1541466..f8c6c8c5 100644 --- a/tzfile.h +++ b/tzfile.h @@ -26,7 +26,7 @@ #endif /* !defined TZDEFRULES */ -/* See Internet RFC 8536 for more details about the following format. */ +/* See Internet RFC 9636 for more details about the following format. */ /* ** Each file begins with. . . diff --git a/zic.c b/zic.c index cf8e79df..6da35270 100644 --- a/zic.c +++ b/zic.c @@ -2761,7 +2761,7 @@ writezone(const char *const name, const char *const string, char version, if (thisleapexpiry) { /* Append a no-op leap correction indicating when the leap second table expires. Although this does not conform to - Internet RFC 8536, most clients seem to accept this and + Internet RFC 9636, most clients seem to accept this and the plan is to amend the RFC to allow this in version 4 TZif files. */ puttzcodepass(leapexpires, fp, pass); @@ -3007,7 +3007,7 @@ stringzone(char *result, struct zone const *zpfirst, ptrdiff_t zonecount) result[0] = '\0'; - /* Internet RFC 8536 section 5.1 says to use an empty TZ string if + /* Internet RFC 9636 section 6.1 says to use an empty TZ string if future timestamps are truncated. */ if (hi_time < max_time) return -1; -- 2.43.0

1 1

Ukraine to abolish DST?
by Steffen Thorsen Oct. 26, 2024

Oct. 26, 2024

Ukraine seems to be getting rid of DST, according to https://universemagazine.com/en/the-verkhovna-rada-canceled-daylight-saving… "During a meeting of the Verkhovna Rada of Ukraine on June 16, daylight saving time was canceled. According to MP Yaroslav Zheleznyak, 261 MPs voted in favor of the bill. Now it must be signed by the President of Ukraine, and then it will come into force." which is again referencing (in Ukrainan) https://lb.ua/society/2024/07/16/624453_verhovna_rada_skasuvala_perehid.html It seems they will plan to set back time this autumn to winter(standard) time, and then stay on that. Best regards, Steffen Thorsen - timeanddate.com

5 8

Brazil may reinstate daylight saving time soonish
by Paul Eggert Oct. 16, 2024

Oct. 16, 2024

A Reuters report[1] says that energy authorities in Brazil have approved a plan to bring back daylight saving time, to save electrical energy during a major drought that has hurt hydroelectric power generation[2]. As far as I know authorities have not decided or published details of the plan, such as which states would be involved and dates and times of transitions. However, one English-language report says that DST would not start until after the election period ends on October 27[3]. This is not a done deal, as any change would need approval by President Luiz Inácio Lula da Silva. That being said, Brazil's DST was abolished by Lula's predecessor and political opponent Jair Bolsonaro, and Lula did an informal Twitter poll shortly after his election in which 66% of respondents voted for DST[4], so presumably Lula would favor restoring DST. [1]: Rodrigo Viga Gaier and Leticia Fucuchima. Brazil energy authorities approve returning to daylight saving time as drought bites. Reuters. 2024-09-20. <https://www.reuters.com/world/americas/brazil-likely-reinstate-daylight-sav…> [2]: Daylight Saving Time Won’t Fix Brazil’s Energy Crisis. Latin American Post. 2024-09-23. <https://latinamericanpost.com/analysis-en/daylight-saving-time-wont-fix-bra…> [3]: Leonardo Vieceli. Brazil's National Electric Operator Recommends Daylight Saving Time. Folha de S.Paulo. 2024-09-20. <https://www1.folha.uol.com.br/internacional/en/business/2024/09/brazils-nat…> [4]: Amanda Audi. Will Brazil bring back daylight saving time? The Brazilian report. 2024-01-02. <https://brazilian.report/society/2024/01/02/lula-daylight-saving-time/>

1 1

[PROPOSED] Port better to glibc when used internally there
by Paul Eggert Oct. 16, 2024

Oct. 16, 2024

I ran into this problem when compiling an experimental version of glibc, which uses tzcode internally. * private.h (static_assert): Override any definition a nonconforming implementation may provide. --- private.h | 1 + 1 file changed, 1 insertion(+) diff --git a/private.h b/private.h index c3304104..4b035ed7 100644 --- a/private.h +++ b/private.h @@ -51,6 +51,7 @@ #endif #if __STDC_VERSION__ < 202311 +# undef static_assert # define static_assert(cond) extern int static_assert_check[(cond) ? 1 : -1] #endif -- 2.43.0

1 0

Winter Time in Palestine for 2024s year
by heba.hamad Oct. 9, 2024

Oct. 9, 2024

4 4

Potential Inconsistency in tz Database (2024b) for Mexico 1931
by Bogdan Hoancea Sept. 16, 2024

Sept. 16, 2024

Dear IANA Team, I hope this message finds you well. My name is Bogdan Hoancea, and I am a software engineer at ABB. We maintain the software package tzdata<https://www.npmjs.com/package/tzdata>, which utilizes the tz database for generating time zone information. I am reaching out regarding a potential inconsistency I noticed in the latest tz database release (tzdata2024b/northamerica). Specifically, for Mexico in 1931, "May 1 23:00" appears to have been changed to "April 30 0:00," whereas it seems the correct adjustment should have been "Apr 30 0:00," in line with the rest of the table. [cid:image001.png@01DB0854.42FCA410] While it is always a possibility to handle this particular case in our software, I wanted to bring it to your attention in case it impacts other users as well, and also, we would prefer it if the root cause of the issue was handled. Thank you for your continued work in maintaining such a critical resource, and please feel free to reach out if any further information is required. Best regards, Bogdan Hoancea [https://signatures.spiritit.com/ABB_Logo_HR.png]<http://www.abb.com/> - Bogdan Hoancea Software engineer - SpiritIT Measurement & Analytics ABB b.v. Achtseweg Zuid 151A / Strijp-TQ Entrance 5 5651GW Eindhoven, The Netherlands Phone: +31 88 440 47 12 abb.com

2 1

Makefile checknow
by Stephen Colebourne Sept. 15, 2024

Sept. 15, 2024

Hi, The Makefile contains a section called `check_now`. It references the files `zone1970.tab` and `zonenow.tab`. Other sections of the Makefile take account of the variable $ZONETABLES before using/checking zone files. Would it be possible to alter Makefile so it only runs check_now if at least one of zone1970/zonenow are in $ZONETABLES ? eg. something like this (now 100% sure this is the right logic...): check_now: checknow.awk date tzdata.zi zdump zic zone1970.tab zonenow.tab for tab in $(ZONETABLES); do \ rm -fr $@.dir mkdir $@.dir ./zic -d $@.dir tzdata.zi now=$(CHECK_NOW_TIMESTAMP) && \ future=`expr $(CHECK_NOW_FUTURE_SECS) + $$now` && \ ./zdump -i -t $$now,$$future \ $$(find $$PWD/$@.dir/????*/ -type f) \ >$@.dir/zdump.tab $(AWK) \ -v zdump_table=$@.dir/zdump.tab \ -f checknow.awk zonenow.tab rm -fr $@.dir done touch $@ thanks Stephen

2 4

Issue with "April" in northamerica file also breaks Elixir tzdata lib updater (":tzdata_release_updater terminating..."), a dependency of timex
by greg＠rumandcode.io Sept. 11, 2024

Sept. 11, 2024

Just wanted to add to the list of libraries impacted by this issue. tzdata is a dependency of the timex library, one of the most popular in the elixir ecosystem. A 2024c release with the fix would be much appreciated. Best regards, Greg McDonald

4 6

Tzdb: Apr-April Issue: Request to provide ETA for next release with the fix - 2024c
by sattisrinivas89＠gmail.com Sept. 10, 2024

Sept. 10, 2024

Greetings Team, I am writing to bring to your attention a critical issue we've encountered with the recent release of https://github.com/eggert/tz -version 2024b. We are using https://github.com/HowardHinnant/date library for our scheduler, the changes with 2024b have caused our schedulers to fail across thousands of agents. Given the scale of our deployment, manually fixing each affected agent is not a feasible solution for us. I see the issue has been fixed in the repo, I really appreciate making a quick fix. Could you please provide an estimated timeline for when we can expect a new release with the fix. If possible, we would greatly appreciate it if you could expedite the release with the fix. Thank you very much for your prompt attention to this matter. We look forward to your response. Thanks Srinivas.

2 1

2024b
by Christopher Burke Sept. 9, 2024

Sept. 9, 2024

Greetings, I am not sure if this is technically an error from your perspective or not; but the latest 2024b DB does not load using the Azul ZUUpdater Tool. It fails with the following message: Failed: java.lang.Exception: Failed while parsing file '/tmp/ziupdater1990610874409301294343524276772419/srcdir/northamerica' on line 2633 'Rule Mexico 1931 only - April 30 0:00 1:00 D' From looking at the source files this is the only occurrence of a full month string I could find; the rest are 3 letter abbreviations, e.g. Apr. I thought I would let you know in case this was a mistake. Regards Chris Burke This message may contain confidential and/or privileged information and is intended solely for the named recipient. Please notify Air New Zealand immediately if received in error and delete the message (do not distribute further). Views expressed are those of the sender and may not represent Air New Zealand. For more information on the Air New Zealand Group, visit us online at https://www.airnewzealand.com/

5 11

Re: Typo in northamerica file
by Hal Murray Sept. 9, 2024

Sept. 9, 2024

> We are preparing a patch not to auto download but customers will take > time to upgrade agents and until they do the system is down. > We would really appreciate if a new patch - 2024c can be released, so > that it would fix the problems immediately as fix has been made already. If your code is dependent on data from somebody else, your customers should download it from your site so you can check new versions before releasing them to your customers. -- These are my opinions. I hate spam.

1 0

Typo in northamerica file
by Kelvin Wong Sept. 9, 2024

Sept. 9, 2024

Hi Iana, It appears that there is a typo in the latest version of tzdata (2024b), where one of the lines in northamerica should be "Apr" instead of "April". # Rule NAME FROM TO - IN ON AT SAVE LETTER/S Rule Mexico 1931 only - April 30 0:00 1:00 D Would you please check and see if it can be corrected in the next version? Thanks, Kelvin [Insignia-transp] Kelvin Wong VP, Client Services, FlexTrade Systems O: +852 3579 2231 | M: +852 3579 2231 | flextrade.com<http://flextrade.com/> 21/F, New World Tower 1, 16-18 Queen's Road Central, Hong Kong [cid:image002.png@01DB02CD.CF076080]<https://www.linkedin.com/company/flextrade/> [cid:image003.png@01DB02CD.CF076080] This communication is for informational purposes only. The contents of this transmission are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please notify the sender by return email and delete this message from your system. FlexTrade Systems Inc., its subsidiaries and affiliates do not guarantee the completeness and accuracy of this transmission's contents. Moreover, FlexTrade Systems Inc., its subsidiaries and affiliates do not guarantee this communication to be free of viruses and accept no liability for any damage caused thereof.

7 8

Time Zone Database Issues
by Craig Milam Sept. 9, 2024

Sept. 9, 2024

Dear IANA tz-contact team, I'm writing to report an issue with the latest time zone database tzdata2024b. When using the latest tzupdater tool provided by Oracle, I encountered the following error message: Using https://www.iana.org/time-zones/repository/tzdata-latest.tar.gz as source for tzdata bundle. Failed: java.time.zone.ZoneRulesException: Unable to load TZDB time-zone rules java.time.zone.ZoneRulesException: Unable to load TZDB time-zone rules at tools.tzdb.TzdbZoneRulesProvider.<init>(TzdbZoneRulesProvider.java:76) at tools.tzdb.TzdbZoneRulesCompiler.compile(TzdbZoneRulesCompiler.java:174) at tools.tzdb.TzdbZoneRulesCompiler.main(TzdbZoneRulesCompiler.java:83) at com.sun.tools.tzupdater.ExternalModule.compileToJSRBinary(ExternalModule.java:169) at com.sun.tools.tzupdater.TimezoneUpdater.run(TimezoneUpdater.java:252) at com.sun.tools.tzupdater.TimezoneUpdater.main(TimezoneUpdater.java:686) Caused by: java.lang.RuntimeException: Failed while processing file [/tmp/tz.tmp/northamerica] at tools.tzdb.TzdbZoneRulesProvider.load(TzdbZoneRulesProvider.java:221) at tools.tzdb.TzdbZoneRulesProvider.<init>(TzdbZoneRulesProvider.java:74) ... 5 more Caused by: java.lang.IllegalArgumentException: Unknown month: April at tools.tzdb.TzdbZoneRulesProvider$MonthDayTime.parseMonth(TzdbZoneRulesProvider.java:391) at tools.tzdb.TzdbZoneRulesProvider$MonthDayTime.parse(TzdbZoneRulesProvider.java:314) at tools.tzdb.TzdbZoneRulesProvider$MonthDayTime.access$300(TzdbZoneRulesProvider.java:258) at tools.tzdb.TzdbZoneRulesProvider$RuleLine.parse(TzdbZoneRulesProvider.java:561) at tools.tzdb.TzdbZoneRulesProvider.load(TzdbZoneRulesProvider.java:200) ... 6 more The problem appears to be related to North America and specifically affects the time zone rules for this region. The error message indicates that there's an issue with an "Unknown month: April" in one of the time zone rules. I've double-checked my data and haven't found any discrepancies, so I'm assuming the issue is with the database itself. I'd appreciate it if you could investigate this matter further and provide a corrected version of the time zone database as soon as possible. Thank you for your attention to this matter. I look forward to hearing from you soon. Thanks Craig Milam Lead Software Engineer, Trip Support E cmilam(a)netjets.com<mailto:cmilam@netjets.com> M +1 614 906 2849 [Description: C:\TEMP\GlobalSignatureWizard_smyers2_20151123_084819\NetJetsGlobalSignature_Short_files\NJ_Logo.png]<https://www.netjets.com/> NetJets(r) Inc. is a Berkshire Hathaway Company. **** **** **** **** This message contains information which may be confidential and privileged. Unless you are the addressee (or authorized to receive for the addressee), you may not use, copy or disclose to anyone the message or any information contained in the message. If you have received the message in error, please advise the sender by reply e-mail and delete the message.

2 1

corrupted line in latest tz database(tzdb-2024b)
by Abdallah Jaghoob Sept. 9, 2024

Sept. 9, 2024

Hi, We're automatically parsing your latest published tz database in our application and we noticed that the latest published one on Sep 5th 2024 has a corrupted line in the north america file https://data.iana.org/time-zones/tzdb-2024b/northamerica Line 2636 has the following content: Rule Mexico 1931 only - April 30 0:00 1:00 D Following your convention, all months should be 3 letters only, so the file should be: Rule Mexico 1931 only - Apr 30 0:00 1:00 D Thanks, Abdallah

2 1

Re: Weird time delay in data.iana.org 2024b update
by Kerry Shetline Sept. 6, 2024

Sept. 6, 2024

>> Is this perhaps deliberate, to prevent too many people trying to access updated >> timezone data all at once? > > More likely that server or org network access is front-ended by a proxy server > that has to scan everything before it caches it and/or allows anyone to access it. I suppose that could be the issue. The response from https://data.iana.org/time-zones/releases/ has this header: cache-control: max-age=86400 Perhaps what seemed like more than a day of delay was just a bit under.

2 1

Weird time delay in data.iana.org 2024b update
by Kerry Shetline Sept. 6, 2024

Sept. 6, 2024

It appears to me that where on network you access data.iana.org <https://data.iana.org/time-zones/releases/> from might make a difference in what content you get at a given time. Are there mirrored servers that perhaps get delayed updates? I have an automated process that looks for new tzdata releases by periodically checking https://data.iana.org/time-zones/releases/. I had received the mailing from this list that 2024b had been released, but had no sign from my automated process that the update had occurred. My polling interval is 30 minutes, so detection should be fairly fast. If used my own web browser at home to access https://data.iana.org/time-zones/releases/ I could see 2024b. Oddly enough, however, when I SSHed the remote server where my process runs, and used curl at the command line to check https://data.iana.org/time-zones/releases/, 2024b wasn’t there yet. I wondered if my server had simply cached old data, but after a reboot of the server the same stale data came through without 2024b being shown as available. It was at least a full day, maybe more, before 2024b was visible from that remote server. Is this perhaps deliberate, to prevent too many people trying to access updated timezone data all at once?

3 2

ISO 3166 code for Pacific/Johnston
by Chris Walton Sept. 5, 2024

Sept. 5, 2024

Paul, I am looking at a commit you did on Jan 7,2023: https://github.com/eggert/tz/commit/600e78ba0487d82aaa97c00f08b26022d32e3470 Your commit summary reads: > * zone1970.tab (Pacific/Honolulu): Remove UM country code. > This change needed because Pacific/Johston moved to ‘backward’ in > 2017a, due to its not differing from Pacific/Honolulu since 1970. For reference, "UM" is the ISO 3166 code for the *US Minor Outlying Islands* which includes Johnston Atoll. I am not clear why this is a special case for Pacific/Johnston. There are now numerous linked zones in the backward file. Generally you appear to have kept all the relevant ISO 3166 codes in zonetab1970. e.g. there are three links pointing to America/Panama; accordingly the America/Panama entry in zonetab1970 lists all the relevant codes (PA, CA, & KY). So what makes the Pacific/Johnston case differ from the others? -chris

2 2

[tz-announce] 2024b release of tz code and data available
by Paul Eggert via tz-announce Sept. 5, 2024

Sept. 5, 2024

The 2024b release of the tz code and data is available. This release is prompted by the accumulated weight of many non-urgent changes to both code and data. It changes one timestamp abbreviation, for the long-obsolete System V setting TZ='MET'; see below. Otherwise, the timestamps affected by this release all predate April 2008, so you can skip this release if your application uses only tzdata and does not use older timestamps. This release contains the following changes: Briefly: Improve historical data for Mexico, Mongolia, and Portugal. System V names are now obsolescent. The main data form now uses %z. 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. Changes to past timestamps Asia/Choibalsan is now an alias for Asia/Ulaanbaatar rather than being a separate Zone with differing behavior before April 2008. This seems better given our wildly conflicting information about Mongolia's time zone history. (Thanks to Heitor David Pinto.) Historical transitions for Mexico have been updated based on official Mexican decrees. The affected timestamps occur during the years 1921-1927, 1931, 1945, 1949-1970, and 1981-1997. The affected zones are America/Bahia_Banderas, America/Cancun, America/Chihuahua, America/Ciudad_Juarez, America/Hermosillo, America/Mazatlan, America/Merida, America/Mexico_City, America/Monterrey, America/Ojinaga, and America/Tijuana. (Thanks to Heitor David Pinto.) Historical transitions for Portugal, represented by Europe/Lisbon, Atlantic/Azores, and Atlantic/Madeira, have been updated based on a close reading of old Portuguese legislation, replacing previous data mainly originating from Whitman and Shanks & Pottenger. These changes affect a few transitions in 1917-1921, 1924, and 1940 throughout these regions by a few hours or days, and various timestamps between 1977 and 1993 depending on the region. In particular, the Azores and Madeira did not observe DST from 1977 to 1981. Additionally, the adoption of standard zonal time in former Portuguese colonies have been adjusted: Africa/Maputo in 1909, and Asia/Dili by 22 minutes at the start of 1912. (Thanks to Tim Parenti.) Changes to past tm_isdst flags The period from 1966-04-03 through 1966-10-02 in Portugal is now modeled as DST, to more closely reflect how contemporaneous changes in law entered into force. Changes to data Names present only for compatibility with UNIX System V (last released in the 1990s) have been moved to 'backward'. These names, which for post-1970 timestamps mostly just duplicate data of geographical names, were confusing downstream uses. Names moved to 'backward' are now links to geographical names. This affects behavior for TZ='EET' for some pre-1981 timestamps, for TZ='CET' for some pre-1947 timestamps, and for TZ='WET' for some pre-1996 timestamps. Also, TZ='MET' now behaves like TZ='CET' and so uses the abbreviation "CET" rather than "MET". Those needing the previous TZDB behavior, which does not match any real-world clocks, can find the old entries in 'backzone'. (Problem reported by Justin Grant.) The main source files' time zone abbreviations now use %z, supported by zic since release 2015f and used in vanguard form since release 2022b. For example, America/Sao_Paulo now contains the zone continuation line "-3:00 Brazil %z", which is less error prone than the old "-3:00 Brazil -03/-02". This does not change the represented data: the generated TZif files are unchanged. Rearguard form still avoids %z, to support obsolescent parsers. Asia/Almaty has been removed from zonenow.tab as it now agrees with Asia/Tashkent for future timestamps, due to Kazakhstan's 2024-02-29 time zone change. Similarly, America/Scoresbysund has been removed, as it now agrees with America/Nuuk due to its 2024-03-31 time zone change. Changes to code localtime.c now always uses a TZif file's time type 0 to handle timestamps before the file's first transition. Formerly, localtime.c sometimes inferred a different time type, in order to handle problematic data generated by zic 2018e or earlier. As it is now safe to assume more recent versions of zic, there is no longer a pressing need to fail to conform RFC 8536 section 3.2, which requires using time type 0 in this situation. This change does not affect behavior when reading TZif files generated by zic 2018f and later. POSIX.1-2024 removes asctime_r and ctime_r and does not let libraries define them, so remove them except when needed to conform to earlier POSIX. These functions are dangerous as they 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 supports POSIX.1-2024 proleptic TZ strings. Also, it assumes POSIX.2-1992 or later, as practical porting targets now all support that, and it uses some features from POSIX.1-2024 if available. Changes to build procedure 'make check' no longer requires curl and Internet access. The build procedure now assumes POSIX.2-1992 or later, to simplify maintenance. To build on Solaris 10, the only extant system still defaulting to pre-POSIX, prepend /usr/xpg4/bin to PATH. Changes to documentation The documentation now reflects POSIX.1-2024. Changes to commentary Commentary about historical transitions in Portugal and her former colonies has been expanded with links to many relevant legislation. (Thanks to Tim Parenti.) Here are links to the release files: https://www.iana.org/time-zones/repository/releases/tzcode2024b.tar.gz https://www.iana.org/time-zones/repository/releases/tzdata2024b.tar.gz https://www.iana.org/time-zones/repository/releases/tzdb-2024b.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 6903dde39ed637adaafc352c4b6993739253f058 dated 2024-09-04 12:27:47 -0700 and tagged '2024b' in the development GitHub repository at <https://github.com/eggert/tz>. Here are the SHA-512 checksums for the release files: 0e4e872d6c6d9e2ce8c4e567fcbb7658942b8544157d1e48673d9cb989f3af3379fa58e7a71ab98f4a8f2ac6727de1f8c4cd1981053409ebd8989345dc640026 tzcode2024b.tar.gz 0d86686e215672343debb3471b7e7ccb8a27f063f085c9b532d5e0470377843daa0dfb6aee0db4fb9068dd52810c69aeee914a1a7c7e603fdecda7e855020193 tzdata2024b.tar.gz 72446e5cf445515512437c8deaae3063b093aab9620d6441cafaa9b3b71603c857f7ba53557579595788bbc901cd6142404b4db6b0e9f2b23d57b2b3cbc837a8 tzdb-2024b.tar.lz Here are GPG digital signatures for the release files: -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmbYtYgACgkQ7ZfpDmKq fjTPkRAAvusnEE+0TDcfXqA/eEr4LksyAWMjLcIU+xakuXqbBGbGZIeEeDjT58f5 IWhKZyEc6JPgL9T/0TSBUW0IwC8JqiYkK3oovQPlcQkufwkCe2GNqAEWVRuT9Y4H trFGM53tNJJA6GySNBCvtaglIkj7vCQJ+gQ/NACEcxlxypy0TRRqAG9ZcUT8HpRI Hh5+TTBJdxG9PqLBI/INbKlEvpFovMjV0UXvlqfO/R2vanZTOlanjW3/g0PgzcfO GvNRTC8R0N49rrieGj4iUUDPaSi7rPW9hLX6OQDc3ASUjTXHw7uL1fkVTCUdF+so f6r9UTrTjOofQOjziR1BfA+SRv79mWOLSxW+yJDYLPkPjEEIUnmIoIoSrDXdqXC3 p7nWOJzFGEw7Q8FBBzOtcFPOiLohNe+zg3reAy4P5Uw8P8DeYm0T/jaZUQGLF2gx Xp60+KkzGuorfzPECqzUW4RNT/+7hVChf+bxRQ14upnpx+rjBxZMX9lFEzismF4p v3cCAPJ038CHDSXkwnBefKRLoWhzbov/MxJ+FgbksuhlaO/0OdQsP4e8tv8RhvHk tTl07n7tU8NPO1J6osEIRXggVKW/fo+ifCtmkHqvE21vtSq1NccYZYphkvZlQdmk oHFyAIxRdgEv2iS4KGlXeY062ZiSKAy0LdhEIFcGr59bLE9wPuA= =tdRE -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmbYtYgACgkQ7ZfpDmKq fjRqPA/+N+f7KwPQJYYFtLWudtXxGIVEYDsBtHcqlj20FsdgsKk/9cdm3zKTWFuF a5uKn6plxwN6hmXjrwV7nBV6M8kxeqRP4Zf+rCdNMWhLGSmHmDCU+1m5SPYs/+Xh P2W3pc310pQocGtMIsYoVYrEtQl/K4p7V6jxAaG8QTpWmt0K6RS+LxxfqgKbmq14 tU8Jznx/LBFbvEmQxNAGKzq58ce7yexIRRGvetHGWvwafb9+Vv2CiOx+oCS2GeEF APO2UdbZCiUaTJYZPtg2vnk2pGDrTAO/jsEe486iKinVAOkJyBckn/yqykh5NLCk q+MtRngIinrV88KqpmW1OXuAKjJJLXrveAKoZKVbvMuzBAMG1YvAo9CzBwHYfKhW bxLo9q9HyRgci9xoMOeVi1xabTm+NkhbqQuu15rQLlgXoMYm/4x9PbP7JSeuB8N0 vyGjyD+tZtDXgPC3AARmpPuabDQQ9BM0RJ5exUOkcAbvYyFE3bVHLPk28iZOzg8r Y/BSUOXIj7Jb+ZOuIkuDRWHvDifTBrpPDDlwY4JWUfRhx2HhrFjD59SJt6kPNsJE KAjVQREtXDtnqu3bZ7AsKzckpFlrlk0vYfeKaL5N3O6iEpggmE0LTWDXRcrzESh5 E1uQBnIrS4CHuso1wZRy0FHJYvSKGbRCN3jHyJBRSGgBTFGOuIY= =AXnJ -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmbYtYkACgkQ7ZfpDmKq fjSLXhAAnP1lRfPZ5pQhV57GAvYgMyrHpQbnBmZUHLESPRlqETzjDiA/n/tpaWBz ypvD91O0O5F2jf7JTGO8OgN3UARuOLE+Ry/gtW01udC4Z083ALsLovJKx7DbaCcc KwxK9Ia1++T/nulJsEH5b+6w78ptUbqnbwIdwzqDnImJn3OFdAJddapI/z6iDDEh 9EzSlykcHec9aYdC9KEFJaPjzABxDlbqhDM3QEkheFHXiZtt6fTg3fH+B3uetvix IfHAyYA6iJxezY/rqr+k5loa+ObTj8Rh11bF0OPJoWVMWLNDDWUa/h/SIm5zfD64 wl2aRw+yYSB1Fp1W9zOxJJyYnJvlBsNBU1KZEjNaCxbjcmeUtwyYv3tl8dq8NABL KhafPI6Cvw8NAI4c7JI2lDbLdLTxRNMar5uDhXPFZ6CGbBGwjyiVR2j73FjgngUk nHC2jw3UudfrkyWArArIwUPz0GKtgkQPTGUnWn1lZZP3QI1rM5Vhk17s88E2Igls AkHZYPI8X6118u+deVsyG9d+8v/vNbPkMMC/wqv4tqJva4Yu8QSWP6ZLFZhO1r6q 2ZHEEGPftF0tZETkWLr4Ndpbny6a2jeNaT9/qBRjSDpD4hIdBgYbfa3jKFlNZAx6 o9xVZy0n5MgXh2FOFFWIepYhQvwngnaw0kf3YqTkk+4xcKsgM3w= =qqXx -----END PGP SIGNATURE-----

3 2

breaking change in 2024b
by Howard Hinnant Sept. 5, 2024

Sept. 5, 2024

A change to this commit: https://github.com/eggert/tz/commit/812aff32b32c02266361d5538351e0db2a1aee5b has broken the database parser I wrote. I believe it to be an accidental breakage. “April” was used instead of “Apr”. This is the only place in the database that full month names are used. Would it be possible to fix this and issue a new release? Howard

3 2

[PROPOSED 1/2] "Apr", not "April", in IN column
by Paul Eggert Sept. 5, 2024

Sept. 5, 2024

* northamerica (Rule): Use "Apr", not "April", in the IN column. Both forms are valid, but "Apr" is more consistent. Problem reported by Howard Hinnant. --- northamerica | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/northamerica b/northamerica index 01f392e0..1af874b6 100644 --- a/northamerica +++ b/northamerica @@ -2631,7 +2631,7 @@ Zone America/Dawson -9:17:40 - LMT 1900 Aug 20 # http://puentelibre.mx/noticia/ciudad_juarez_cambio_horario_noviembre_2022/ # Rule NAME FROM TO - IN ON AT SAVE LETTER/S -Rule Mexico 1931 only - April 30 0:00 1:00 D +Rule Mexico 1931 only - Apr 30 0:00 1:00 D Rule Mexico 1931 only - Oct 1 0:00 0 S Rule Mexico 1939 only - Feb 5 0:00 1:00 D Rule Mexico 1939 only - Jun 25 0:00 0 S -- 2.43.0

1 1