- 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. 7, 2024

Sept. 7, 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. 7, 2024

Sept. 7, 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. 6, 2024

Sept. 6, 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. 6, 2024

Sept. 6, 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

Philippines might reintroduce DST
by Steffen Thorsen Sept. 2, 2024

Sept. 2, 2024

The House committee approved a bill to advance Philippine Standard Time by one hour during the first six months of the year as a preventive measure against productivity loss caused by the dry season. It requires the president's approval to actually take effect. The bill is from 2023: https://issuances-library.senate.gov.ph/bills/house-bill-no-7750-19th-congr… This is according to multiple news sources such as: https://www.philstar.com/headlines/2024/08/31/2381791/house-panel-oks-measu… https://philstarlife.com/news-and-views/917709-house-approves-daylight-savi… https://www.esquiremag.ph/long-reads/features/history-of-daylight-savings-t… Best regards, Steffen Thorsen - timeanddate.com

1 0

Mailman Upgrade Announcement
by David Dong Aug. 27, 2024

Aug. 27, 2024

Hello, Over the coming days the infrastructure behind this mailing list will be upgraded. IANA hosts a number of operational mailing lists using ICANN's mailing list infrastructure. This infrastructure is currently undergoing a major upgrade, including to the mailman software that operates this list. Users should not observe a difference except for modernization of the mailing list administration website. Mailing list archives will move to a new archiver, but old archives will be retained to preserve references to archived messages. The archives may be delayed by several hours during the migration. We will send an announcement following the migration that will also serve as a confirmation of the operational status of the mailing list and will provide a link to the new archives. If you have problems caused by the migration, please contact the IANA team at iana(a)iana.org so we may help remedy them. Best regards, David Dong IANA Services Sr. Specialist

4 6

FW: Europe/Dublin
by josephcaggiano＠ups.com Aug. 21, 2024

Aug. 21, 2024

From: Joseph Caggiano Sent: Tuesday, August 20, 2024 3:05 PM To: tz(a)iana.org Cc: Douglas Weichert <dweichert(a)ups.com>; Autumn McPhillips <amcphillips(a)ups.com>; Matt Taylor <mxtaylor(a)ups.com>; Vinothkumar Vamanan <vinothkumarvamanan(a)ups.com> Subject: Europe/Dublin Hello, Our team has an application on a monthly basis which downloads the latest time zone tar file from IANA.org and processes the files to load tables with the time zones and rule information. We were recently informed our offset information for Europe/Dublin was incorrect. Based upon our team's analysis of this zone and rule, it appears the zone may be assigned to an incorrect rule (Eire). A similar zone, Europe/London, is assigned to the EU rule. [cid:image001.png@01DAF310.A356C510] Please advise if this information is accurate and if not, can it be updated. Thank you. Joe Caggiano Lead Data Engineer - CRD 201-828-2303 josephcaggiano(a)ups.com<mailto:josephcaggiano@ups.com>

3 2

Request to Include DateTimeOnline in "Time Zone and Daylight Saving Time Data" Page
by Santosh Sahu Aug. 21, 2024

Aug. 21, 2024

Dear TZ team, I hope you are doing well. Over the past two years, with considerable effort and dedication, I have developed a website called DateTimeOnline<https://www.datetimeonline.com/>. This platform provides comprehensive information on date, time, time zones, and daylight-saving time for over 35,000 locations worldwide. Additionally, it offers weather details for these places and includes a time zone converter<https://www.datetimeonline.com/time_zone_converter.php>, allowing users to compare the time between two locations quickly. If you find it valuable, I would be honoured if you consider including a link to DateTimeOnline<https://www.datetimeonline.com/> <https://www.datetimeonline.com/> in your website's "Time Zone and Daylight Saving Time Data<https://web.cs.ucla.edu/~eggert/tz/tz-link.html>" page. Thank you for your time and consideration. Best regards, Santosh Sahu santosh.sahu(a)datetimeonline.com<mailto:santosh.sahu@datetimeonline.com> [cid:730d3fc6-203f-46b0-94fd-892fd353e141]

1 0

Past changes in Mexico
by Heitor David Pinto Aug. 21, 2024

Aug. 21, 2024

Hello, I'd like to suggest several corrections to past time changes in Mexico. In 1931, the decree implementing DST specified that it would take effect on 30 April, so I suppose that DST started on that date at 0:00. The database currently says 1 May at 23:00. https://www.dof.gob.mx/nota_to_imagen_fs.php?cod_diario=192270&pagina=2&sec… In 1981, the decree changing Campeche, Yucatán and Quintana Roo to UTC-5 specified that it would enter into force on 26 December 1981 at 2:00. The database currently says 23 December 1981, which was the date of publication of the decree. https://www.dof.gob.mx/nota_to_imagen_fs.php?codnota=4705667&fecha=23/12/19… In 1982, the decree returning Campeche and Yucatán to UTC-6 specified that it would enter into force on 2 November 1982 at 2:00. The database currently says 2 December 1982. https://www.dof.gob.mx/nota_to_imagen_fs.php?cod_diario=205689&pagina=3&sec… Quintana Roo changed to UTC-6 on 4 January 1983 at 0:00, and again to UTC-5 on 26 October 1997 at 2:00. These changes are not currently included in the database. https://www.dof.gob.mx/nota_to_imagen_fs.php?codnota=4787355&fecha=28/12/19… https://www.dof.gob.mx/nota_to_imagen_fs.php?cod_diario=209559&pagina=15&se… Durango, Coahuila, Nuevo León and Tamaulipas were set to UTC-7 on 1 January 1922, and changed to UTC-6 on 10 June 1927. Then Durango, Coahuila and Nuevo León (but not Tamaulipas) returned to UTC-7 on 15 November 1930, observed DST in 1931, and changed again to UTC-6 on 1 April 1932. The database currently shows all these states set to UTC-6 on 1 January 1922. https://www.dof.gob.mx/nota_to_imagen_fs.php?codnota=4441846&fecha=29/12/19… https://www.dof.gob.mx/nota_to_imagen_fs.php?codnota=4541520&fecha=09/06/19… https://www.dof.gob.mx/nota_to_imagen_fs.php?codnota=4491963&fecha=15/11/19… https://www.dof.gob.mx/nota_to_imagen_fs.php?codnota=4418437&fecha=21/01/19… The database currently shows the time change of 10 June 1927 occurring at 23:00 in all time zones that have such change. However, the decree only said 10 June 1927, without specifying a time, so I suppose that it should be considered at 0:00. https://www.dof.gob.mx/nota_to_imagen_fs.php?codnota=4541520&fecha=09/06/19… In 1942, the decree changing Baja California, Baja California Sur, Sonora, Sinaloa and Nayarit to UTC-7 was published on 24 April, but it said that it would apply from 1 April, so it's unclear when the change actually occurred. The database currently shows 24 April 1942. https://www.dof.gob.mx/nota_to_imagen_fs.php?cod_diario=192203&pagina=2&sec… Baja California Sur, Sonora, Sinaloa and Nayarit never used UTC-8. The database shows these states changing to UTC-8 on 14 January 1949, but this change only occured in Baja California. https://www.dof.gob.mx/nota_to_imagen_fs.php?codnota=4515613&fecha=13/01/19… In 1945, the decree changing Baja California to UTC-8 specified that it would take effect on the third day from its publication. It was published on 12 November, so it would take effect on 15 November. The database currently says 12 November 1945. https://www.dof.gob.mx/nota_to_imagen_fs.php?codnota=4555049&fecha=12/11/19… In 1948, the decree changing Baja California to UTC-7 specified that it would take effect on "this date". The decree was made on 13 March, but published on 5 April, so it's unclear when the change actually occurred. The database currently shows 5 April 1948. https://www.dof.gob.mx/nota_to_imagen_fs.php?cod_diario=188624&pagina=2&sec… In 1949, the decree changing Baja California to UTC-8 was published on 13 January, but it said that it would apply from 1 January, so it's unclear when the change actually occurred. The database currently shows 14 January 1949. https://www.dof.gob.mx/nota_to_imagen_fs.php?codnota=4515613&fecha=13/01/19… Baja California also observed UTC-7 from 1 May to 24 September 1950, from 29 April to 30 September 1951 at 2:00, and from 27 April to 28 September 1952 at 2:00. These changes are not currently included in the database. https://www.dof.gob.mx/nota_to_imagen_fs.php?codnota=4600403&fecha=29/04/19… https://www.dof.gob.mx/nota_to_imagen_fs.php?codnota=4623553&fecha=23/09/19… https://www.dof.gob.mx/nota_to_imagen_fs.php?codnota=4469444&fecha=27/04/19… https://www.dof.gob.mx/nota_to_imagen_fs.php?codnota=4533868&fecha=10/03/19… All changes in Baja California from 1948 to 1952 match those in California, on the same dates or with a difference of one day. So it may be easier to implement these changes as DST with rule CA during this whole period. Regards, David

2 2

Re: Ukraine to abolish DST?
by Yuriy Novostavskiy Aug. 16, 2024

Aug. 16, 2024

+ CC On Fri, Aug 16, 2024 at 6:19 PM Yuriy Novostavskiy <yuriy(a)novostavskiy.kiev.ua> wrote: > > Hi Paul, > > This small update is just a heartbeat that has no updates so far, but > it's on my eye and I will update you when something changes. > > To fully clarify what the current status is and the expected next steps: > Parliament voted for https://itd.rada.gov.ua/billInfo/Bills/Card/4294 > and document reached required amount of votes, but to become a bill > this document should be signed by the President has not happened yet, > moreover, it has not even been signed by the Chairman of the Parlament > which is just a bureaucracy formality, but without that step, the > document will not be given to President for signature.It's quite an > unusual delay in the processing of bills. The whole story of that > document is quite long, it appeared back in 2020 and was just added to > the vote list in 2024. > > Another document that you mentioned > https://itd.rada.gov.ua/billInfo/Bills/Card/44572, it's a project of > the decision to reject the first one, but it's not even planned to > vote in the Parlament. > > So, stay tuned. > > On Thu, Jul 18, 2024 at 11:09 AM Yuriy Novostavskiy > <yuriy(a)novostavskiy.kiev.ua> wrote: > > > > I assumed that changes would technically take affects on March 30, > > 2025, when DST will not be introduced. Anyway, I propose to keep those > > changes in "work in progress" status until a new law is finally signed > > and published, and in the final text will have clear understanding of > > 'de jure' cut-off date. > > > > I will keep it tracked and will inform you. > > > > BR/Yurii > > > > On Wed, Jul 17, 2024 at 10:20 PM Paul Eggert <eggert(a)cs.ucla.edu> wrote: > > > > > > Thanks for the heads-up about the bill. I found a copy on the Rada > > > website[1]. Assuming the president signs it and it becomes law, we'll > > > need a change and a new TZDB release. > > > > > > The bill says that the law would take effect three months after > > > promulgation, so it'd be helpful to find out its promulgation date > > > whenever that happens to be. > > > > > > A further proposed resolution was introduced today[2] to annul > > > yesterday's decision and stick with the status quo, on the grounds that > > > yesterday's decision wasn't properly conducted. Not knowing Ukrainian > > > politics, I don't know how today's proposal will affect matters. > > > > > > I am attaching a draft TZDB patch but I haven't installed it into the > > > development version, because the effective date isn't known (I > > > approximated it as "2025" in the draft patch), the bill as it stands > > > might not become law, and the patch will need commentary. The > > > zonenow.tab part of the draft patch would be temporary and that file > > > would need to be updated further after 2024-10-27 as Ukraine would merge > > > with Libya and Kaliningrad for future timestamps. > > > > > > [1]: https://itd.rada.gov.ua/billInfo/Bills/Card/4294 > > > [2]: https://itd.rada.gov.ua/billInfo/Bills/Card/44572

1 0

netherland timezone UTC offset (0:19:32.13) history
by Eitan Adler Aug. 6, 2024

Aug. 6, 2024

(I am not currently subscribed, please keep me CCed) Hi all, I'm interested in some specific timezone history. Specifically I'm curious about the origin of 'STDOFF 0:19:32.13'. Does anyone have an authoritative source for where this is derived from? Below is what I found so far: 1. In "NEWS" there is this entry: === zic now accepts subsecond precision in expressions like 00:19:32.13, which is approximately the legal time of the Netherlands from 1835 to 1937... === 2. Wikipedia here https://en.wikipedia.org/wiki/UTC%2B00:20 says === The reason for the specific offset of +0h 19m 32.13s was that the time zone was centered on the mean solar time of the Westertoren (4° 53' 01.95" E Longitude), the tower of the Westerkerk church in Amsterdam. === but I can't find any reference to this specific offset in any of the sources listed on Wikipedia. It is possible I missed the reference though. https://articles.adsabs.harvard.edu/pdf/1909Obs....32..297. https://books.google.com/books?id=MbA-AQAAIAAJ&pg=PA75&printsec=frontcover&… 3. I've seen several references that cite *to* wikipedia or tzdata, but I haven't been able to find anything older. (if this is off topic for the mailing list I apologize, this is the best place I could find) -- Eitan Adler

4 4

[PROPOSED] Mention Internet RFC 9557
by Paul Eggert Aug. 1, 2024

Aug. 1, 2024

--- theory.html | 5 +++++ tz-link.html | 20 ++++++++++++-------- 2 files changed, 17 insertions(+), 8 deletions(-) diff --git a/theory.html b/theory.html index 10281af1..d3573ede 100644 --- a/theory.html +++ b/theory.html @@ -581,6 +581,11 @@ in decreasing order of importance: some sense undefined; this notation is derived from <a href="https://datatracker.ietf.org/doc/html/rfc3339">Internet <abbr title="Request For Comments">RFC</abbr> 3339</a>. + (The abbreviation 'Z' that + <a href="https://datatracker.ietf.org/doc/html/rfc9557">Internet + <abbr>RFC</abbr> 9557</a> uses for this concept + would violate the POSIX requirement + of at least three characters in an abbreviation.) </li> </ul> diff --git a/tz-link.html b/tz-link.html index 739d07af..4d883883 100644 --- a/tz-link.html +++ b/tz-link.html @@ -193,9 +193,10 @@ After obtaining the code and data files, see the <code>README</code> file for what to do next. 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 timezone information format (<dfn><abbr>TZif</abbr></dfn>) -specified by <a href="https://datatracker.ietf.org/doc/html/8536">Internet -<abbr>RFC</abbr> 8536</a>. +are in a special format specified by +<a href="https://datatracker.ietf.org/doc/html/8536">The +Time Zone Information Format (<abbr>TZif</abbr>)</a> +(Internet <abbr title="Request For Comments">RFC</abbr> 8536). The code also lets you read a <abbr>TZif</abbr> file and interpret timestamps for that location.</p> @@ -262,8 +263,8 @@ Studio Code</a>. <p> For further information about updates, please see <a href="https://datatracker.ietf.org/doc/html/rfc6557">Procedures for -Maintaining the Time Zone Database</a> (Internet <abbr -title="Request For Comments">RFC</abbr> 6557). More detail can be +Maintaining the Time Zone Database</a> (Internet <abbr>RFC</abbr> 6557). +More detail can be found in <a href="theory.html">Theory and pragmatics of the <code><abbr>tz</abbr></code> code and data</a>. <a href="https://a0.github.io/a0-tzmigration/">A0 TimeZone Migration</a> @@ -1174,9 +1175,12 @@ headers.</li> <li> <a href="https://datatracker.ietf.org/doc/html/rfc3339">Date and Time on the Internet: Timestamps</a> (Internet <abbr>RFC</abbr> 3339) -specifies an <abbr>ISO</abbr> 8601 -profile for use in new Internet -protocols.</li> +specifies an <abbr>ISO</abbr> 8601 profile for use in new Internet protocols. +An extension, <a href="https://datatracker.ietf.org/doc/html/rfc9557">Date +and Time on the Internet: Timestamps with Additional Information</a> +(Internet <abbr>RFC</abbr> 9557) extends this profile +to let you specify the <code><abbr>tzdb</abbr></code> timezone of a timestamp +via suffixes like "<code>[Asia/Tokyo]</code>". <li> <a href="https://web.archive.org/web/20190130042457/https://www.hackcraft.net/web/da…">Date & Time Formats on the Web</a> surveys web- and Internet-oriented date and time -- 2.43.0

1 0

Fwd: Bulletin C number 68
by Tim Parenti July 30, 2024

July 30, 2024

No leap second 2024-12-31, per below. See attached patch. -- Tim Parenti ---------- Forwarded message --------- From: IERS EOP Product Center <iers.eoppc(a)obspm.fr> Date: Thu, 4 Jul 2024 at 10:57 Subject: Bulletin C number 68 To: <bulc.iers(a)obspm.fr> INTERNATIONAL EARTH ROTATION AND REFERENCE SYSTEMS SERVICE (IERS) SERVICE INTERNATIONAL DE LA ROTATION TERRESTRE ET DES SYSTEMES DE REFERENCE SERVICE DE LA ROTATION TERRESTRE DE L'IERS OBSERVATOIRE DE PARIS 61, Av. de l'Observatoire 75014 PARIS (France) Tel. : +33 1 40 51 23 35 e-mail : services.iers(a)obspm.fr http://hpiers.obspm.fr/eop-pc Paris, 04 July 2024 Bulletin C 68 To authorities responsible for the measurement and distribution of time INFORMATION ON UTC - TAI NO leap second will be introduced at the end of December 2024. The difference between Coordinated Universal Time UTC and the International Atomic Time TAI is : from 2017 January 1, 0h UTC, until further notice : UTC-TAI = -37 s Leap seconds can be introduced in UTC at the end of the months of December or June, depending on the evolution of UT1-TAI. Bulletin C is mailed every six months, either to announce a time step in UTC, or to confirm that there will be no time step at the next possible date. Christian BIZOUARD Director Earth Orientation Center of IERS Observatoire de Paris, France

2 1

Parts of Georgia and Ukraine observing Moscow time
by Heitor David Pinto July 22, 2024

July 22, 2024

Hello, Sources indicate that Abkhazia has observed Moscow time since at least 2010:https://web.archive.org/web/20100725215624/http://abkhazia.travel:80/a… It's possible that South Ossetia has done the same. Both regions definitely changed to UTC+3 along with Moscow in 2014, and have remained in that time zone since then:https://www.kavkaz-uzel.eu/articles/251354/ In Ukraine, the portions of Donetsk and Luhansk regions administered by separatists have observed Moscow time since 2014:https://tass.com/world/756540 In 2022, the portions of Donetsk, Luhansk, Zaporizhzhia and Kherson regions administered by Russia also changed to Moscow time:https://tass.com/society/1568025https://tass.com/society/1605439 I understand that these changes are controversial, but the database does show Crimea in Moscow time since 2014, even though it remains under country code UA in file zone.tab. So I suppose that these other regions should be added as well, under codes GE and UA but showing their time zones observed in practice. Regards,David

2 1

Ukraine canceled DST in autumn of 2024
by Yuriy Novostavskiy July 17, 2024

July 17, 2024

Parlament of Ukraine decided to cancel introducing DST, so, starting from spring 2025 DST will not be used for Kyiv time zone. That law was proposed in 2020, and accepted July 17, 2024. Info on the parlament site of Ukraine https:// w1.c1.rada.gov.ua/pls/zweb2/webproc4_1?pf3511=70150 BTW, that decision should be finally approved by President that is not happened yet

1 0

Contributions of core, mantle and climatological processes to Earth’s polar motion
by Brooks Harris July 16, 2024

July 16, 2024

Contributions of core, mantle and climatological processes to Earth’s polar motion https://www.nature.com/articles/s41561-024-01478-2

1 0

Re: [tz] Time for a Lunar time zone? -Brooks
by Paul Eggert July 11, 2024

July 11, 2024

On 3/2/23 09:51, Brooks Harris wrote: > Will we need DST on the Moon? :-) I hope not! The Moon's axis tilts only 1.5°, much less than the 23.5° of Earth's axis, so seasonal effects on sunlight duration are much less intense on the Moon and there should be less need for Earth-like DST. A more pressing issue is that the length of day (including daytime and nighttime) varies more on the Moon. Local Earth days vary by at most 0.008 hours from the mean of 24 hours (this variation is due to the eccentricity of the Earth orbit and the obliquity of the ecliptic). So people who think that every local Earth day is exactly 24 hours are not far off. Local lunar days, in contrast, are roughly 29.5 ± 0.25 Earth days (again, this includes both lunar daytime and lunar nighttime). That's more slop to deal with, relatively speaking, and dealing with varying-length days could be a bit of a problem for civil time on the Moon. Presumably ESA's boffins are on top of this.....

4 5

Earth's inner core has slowed so much it's moving backward
by Brian Inglis July 5, 2024

July 5, 2024

Newer info related to leap second distribution and occurrences. Earth’s core has slowed so much it’s moving backward, scientists confirm: https://www.cnn.com/2024/07/05/science/earth-inner-core-rotation-slowdown-c… Inner core backtracking by seismic waveform change reversals: https://www.nature.com/articles/s41586-024-07536-4 TL;DR: Seismologists confirm ~70 year inner core oscillation cycle. Inner core rotated eastward faster than the planet 2003-2008 and back ~ 2.5* more slowly westward 2008-2023 over the same path relative to the mantle. Mantle density anomalies and mantle and core boundary topography gravitational coupling could explain LoD Length of Day SYO 6 Year Oscillation. Slower core spin, speeds up the mantle, the planet rotates faster, and the LoD shortens by ms. Core rotation should speed up again in 5-10 years if model is confirmed. -- 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