- tz - lists.iana.org

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