- tz - lists.iana.org

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

11 Sep '24

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 10 Sep '24

10 Sep '24

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 09 Sep '24

09 Sep '24

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 09 Sep '24

09 Sep '24

> 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 09 Sep '24

09 Sep '24

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 09 Sep '24

09 Sep '24

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 09 Sep '24

09 Sep '24

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 06 Sep '24

06 Sep '24

>> 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 06 Sep '24

06 Sep '24

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 05 Sep '24

05 Sep '24

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