September 2024 - tz - lists.iana.org

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