- tz - lists.iana.org

Issue with America/Nuuk tz
by Dan Juskevicius June 20, 2025

June 20, 2025

Dear sir or madam, I'm currently working on an issue that one of our customers has reported with the tz database. Using the latest release (2025b), I have been able to reproduce an issue with America/Nuuk time where it reports at -02 instead of -01; I realize that as of 2023-03-25 the America/Nuuk time zone changed its standard time from -03 to -02, but it appears that it is not represented correctly in the tzdb. All other time zones in the database appear to be represented correctly, so I'm trying to narrow down the root cause of the issue but don't know where to look. Has anyone else reported issue with the America/Nuuk tz, and if so, is there a workaround for this? Cheers, Daniel Juskevicius Systems Software Developer djuskevicius(a)qnx.com QNX - It all starts here ---------------------------------------------------------------------- This email and any attachments are intended solely for the use of the individual or entity to whom they are addressed. This email may contain information that is confidential, privileged, or otherwise protected from disclosure. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this email in error, please immediately contact the sender and delete all copies of this email and any attachments from your systems. Any unauthorized review, use, dissemination, distribution, or reproduction of this email by unintended recipients is not authorized and may be unlawful. Thank you for your cooperation.

5 9

TZif Version Selection Issue in tzcode2025b
by PATAN JEELAN BASHA June 11, 2025

June 11, 2025

Hi All, We have encountered an issue after upgrading to tzcode2025b, where zoneinfo files that were previously generated in TZif3 format are now being generated in TZif2 format. This change appears to be due to the removal of the forced version in the writezone() call in zic.c file. Upon investigation, we found that: ->The logic in stringrule() that sets compat = 2013 based on wdayoff is not meaningful in practice. ->For rules like Sun>=8, wdayoff = 0, so compat = 0, and the compiler now generates TZif2. ->This behavior change appears to result from the removal of the forced version and the introduction of dynamic version selection logic. For example, in the northamerica file, we have: Rule US 2007 max - Mar Sun>=8 2:00 1:00 D Rule US 2007 max - Nov Sun>=1 2:00 0 S These rules are used by zones such as America/Chicago and others. Since Sun>=8 results in wdayoff = 0, the compat value remains 0, and the compiler now generates TZif2 instead of TZif3. This change affects all zones relying on similar rules, even though the rule definitions themselves have not changed. Specifically, the change from: writezone(zpfirst->z_name, envvar, ZIC_VERSION); // older code to: writezone(zpfirst->z_name, envvar, version, defaulttype); // new code has caused the compiler to emit TZif2 for rules that previously resulted in TZif3. We believe this logic does not reliably reflect the need for TZif3 and may lead to inconsistent or unexpected output formats. We would appreciate your thoughts on this and whether a patch or enhancement is planned to address it. Best Regards, Jeelan

3 3

Cape Breton Island "time zone"
by Arthur Olson June 10, 2025

June 10, 2025

"Google and Meta search both report that Cape Breton Island has its own time zone 12 minutes ahead of mainland Nova Scotia time because they are both drawing that information from a Beaverton article I wrote in 2024." --Janel Comeau (The Beaverton is a Canadian satire publication. Folks on this mailing list: be alert for Cape Breton Island come 2026-04-01.) --@dashdashado https://www.threads.com/@janelcomeau/post/DKs2YqBJgqK/google-and-meta-searc… https://thebeaverton.com/2024/07/cape-breton-to-create-new-more-annoying-ti…

1 0

Fix example for zic transition coalescence
by Tim Parenti May 30, 2025

May 30, 2025

I noticed a typo in zic.8 within the "correct" example given for how zic handles/coalesces certain transitions. While I was there, it also made sense to expand a bit more on where the incorrect interpretation could come from, as a further nod to why we choose instead to have zic coalesce transitions as it does. Documentation patch attached and pushed to the development repository. -- Tim Parenti

1 0

Proposal to Add Asia/Penampang to IANA Time Zone Database
by Denis Martin May 30, 2025

May 30, 2025

Dear tz maintainers, I am submitting a formal proposal to add a new time zone entry: Asia/Penampang. The proposal seeks to represent the distinct historical, geographic, and cultural identity of Penampang and greater Kota Kinabalu (Sabah, East Malaysia) in the IANA Time Zone Database. The full proposal is hosted publicly here: https://github.com/dmmartin/Asia-Penampang-Proposal This submission builds on precedent (e.g., Asia/Kuching for Sarawak) and is fully aligned with the IANA project's criteria for regionally distinct zones, even where UTC offsets are identical. Thank you for your time and consideration. Best regards, Denis Martin Sabah Time Zone Advocacy penampang.tzproposal(a)fakemail.org Denis Martin

3 2

PyCon US Time
by Ee Durbin May 20, 2025

May 20, 2025

PyCon US is an annual gathering for the community using and developing the open-source Python programming language. PyCon US has been held in-person and on-location from 2003 to present with exception for 2020 and 2021 in response to the global COVID-19 pandemic. After an initial three year stint in Washington, D.C. USA PyCon US has been hosted in cities across North America in two-year "cycles". PyCon US makes extensive use of software across an annoying number of online and offline systems. These include GNU/Linux servers, PostgreSQL databases, all web browsers, a mobile application, Raspberry Pis, iPads, Zebra printers, printed materials, and human brain matter. These systems persist year-over-year while our timezone does not. This timezone is proposed to provide a durable solution for ensuring agreement between these systems. After over a decade dealing with these concerns, establishment of this timezone will benefit me directly, as well as those who proceed me by reducing churn in our codebases, and entirely obliviate the need to think during stressful periods of conference planning. It will also benefit my co-workers and those who follow them by dissolving an unnecessary cognitive burden when editing records in our systems, communicating deadlines and schedules, and working with one another remotely. It will also benefit attendees in reasoning about these matters. PyCon US Time is defined to be the local time of the city currently hosting the conference. PyCon US Time transitions at the time that last attendee (Larry Hastings, most often) departs the Development Sprints. We are actively working to improve the historic times for this departure, but estimate 8pm local time for years which have not yet been fully verified. Transitions =========== 2003-02-13 First Annual PyCon announced - Reference: https://www.python.org/psf/press-release/pr20030213/ - Location: Washington DC, USA, -5:00 2005-03-25 PyCon US Washington concludes - New Location: Dallas, TX, USA, -6:00 - Last Attendee Departure: Unconfirmed 2007-03-01 PyCon US Dallas concludes - New Location: Chicago, IL, USA, -6:00 - Last Attendee Departure: Unconfirmed 2009-04-02 PyCon US Chicago concludes - New Location: Atlanta, GA, USA, -5:00 - Last Attendee Departure: Unconfirmed 2011-03-17 PyCon US Atlanta concludes - New Location: Santa Clara, CA, USA, -8:00 - Last Attendee Departure: Unconfirmed 2013-03-21 PyCon US Santa Clara concludes - New Location: Montréal, Québec, Canada, -5:00 - Last Attendee Departure: Unconfirmed 2015-04-16 PyCon US Montréal concludes - New Location: Portland OR, USA, -8:00 - Last Attendee Departure: Unconfirmed 2015-04-16 PyCon US Portland concludes - New Location: Cleveland, OH, USA, -5:00 - Last Attendee Departure: 7:59pm local time 2015-04-16 PyCon US Cleveland concludes - New Location: Worldwide, 0:00 - Last Attendee Departure: Unconfirmed - Reference: https://x.com/pycon/status/1126637785455185920 - Note: After PyCon US 2019, the planned conference cycle in Pittsburgh, PA, USA was undertaken on-line for 2020/2021. 2021-10-12 PyCon US Salt Lake City Launched - New Location: Salt Lake City, UT, USA, -7:00 - Reference: https://pycon.blogspot.com/2021/10/pycon-us-2022-website-and-sponsorship.ht… 2023-04-27 PyCon US Salt Lake City concludes - New Location: Pittsburgh, PA, USA, -5:00 - Last Attendee Departure: Unconfirmed 2025-05-22 PyCon US Pittsburgh concludes (Estimated) - New Location: Long Beach, CA, USA, -8:00 While I appreciate and understand that this submission may appear to be a gag/joke, I am sincere in this request and humbly request that it be considered with sincerity in kind. -Ee Durbin Director of Infrastructure Python Software Foundation

2 2

Request for Update: Iran's Official Time Zone – No Daylight Saving Time Since 2023
by Khalil Kharazi May 19, 2025

May 19, 2025

Dear Time Zone Database Maintainers, I hope this message finds you well. I am writing to bring your attention to an important legal update regarding the official timekeeping policy of the Islamic Republic of Iran. In March 2022, the Iranian Parliament passed legislation to permanently abolish Daylight Saving Time (DST), effective from March 2023. As a result, Iran now observes a fixed time zone of UTC+3:30 throughout the entire year, with no forward or backward clock shifts. This change is now fully implemented across all provinces and official systems within the country. However, it has come to our attention that some international platforms, time services, and applications may still reflect outdated DST rules for Iran, which can lead to errors in scheduling, communication, and automation. Given the widespread reliance on the IANA Time Zone Database (tzdata) by global operating systems and applications, we kindly request that you verify and reflect this official update in the relevant database records (Asia/Tehran) to ensure accurate representation of Iran’s current time zone policy. Should you require further documentation or references to the legislation, I would be glad to provide official sources or translations as needed. Thank you for your attention to this matter and for your continued efforts in maintaining a reliable and globally synchronized time zone system. Sincerely, [Khalil Kharazi]

2 1

Proposed correction for zone.tab and Link: Europe/Uzhgorod to Europe/Uzhhorod
by Sorel Si May 17, 2025

May 17, 2025

Dear tz database maintainers, I would like to propose a correction to the spelling of the Ukrainian city Uzhhorod in the tz database. Currently, the city is referenced as "Uzhgorod" in `zone.tab` and as a Link target: In `zone.tab`: UA +4837+02218 Europe/Uzhgorod Zakarpattya west Link definition (in the `europe` data file): Link Europe/Kyiv Europe/Uzhgorod The spelling "Uzhgorod" (with a 'g') appears to be a transliteration from the Russian language form of the city's name ("Ужгород"). However, Uzhhorod is a city in Ukraine. The official Ukrainian name is "Ужгород". According to the current official Ukrainian national system for romanization of Ukrainian Cyrillic (approved by Resolution No. 55 of the Cabinet of Ministers of Ukraine, January 27, 2010), the Ukrainian letter "г" (which is present in "Ужгород") is transliterated as "h". Therefore, the correct romanized form from Ukrainian is "Uzhhorod". This spelling ("Uzhhorod") is consistently used by official Ukrainian sources, including the Uzhhorod City Council (e.g., uzhhorod-rada.gov.ua) and in national legislative documents. Given this, I propose the following changes for accuracy and consistency with Ukrainian national standards: 1. Update the entry in `zone.tab` to: `UA +4837+02218 Europe/Uzhhorod Zakarpattya west` 2. Update the Link target name to `Europe/Uzhhorod`: `Link Europe/Kyiv Europe/Uzhhorod` This would align the tz database with the official and correct transliteration of the city's name from its native language. Thank you for your time and consideration. Sincerely, Arsenii

5 4

[PROPOSED] Don’t mention iso3166.tab in zone1970.tab comment
by Paul Eggert May 16, 2025

May 16, 2025

* zone1970.tab: Remove mention of iso3166.tab in comment. In FreeBSD iso3166.tab is not installed, which makes the comment confusing in an installed file. Although FreeBSD gets around this problem by editing zone1970.tab, it’d be better if FreeBSD could use zone1970.tab unmodified. --- zone1970.tab | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/zone1970.tab b/zone1970.tab index 36535bdf..f3227405 100644 --- a/zone1970.tab +++ b/zone1970.tab @@ -2,14 +2,14 @@ # # This file is in the public domain. # -# From Paul Eggert (2018-06-27): +# From Paul Eggert (2025-05-15): # This file contains a table where each row stands for a timezone where # civil timestamps have agreed since 1970. Columns are separated by # a single tab. Lines beginning with '#' are comments. All text uses # UTF-8 encoding. The columns of the table are as follows: # # 1. The countries that overlap the timezone, as a comma-separated list -# of ISO 3166 2-character country codes. See the file 'iso3166.tab'. +# of ISO 3166 2-character country codes. # 2. Latitude and longitude of the timezone's principal location # in ISO 6709 sign-degrees-minutes-seconds format, # either ±DDMM±DDDMM or ±DDMMSS±DDDMMSS, -- 2.49.0

2 1

opposition to recent time zone change in Paraguay
by Paul Eggert May 6, 2025

May 6, 2025

An article last week in El Nacional reports ongoing public opposition to Paraguay's decision to not fall back on March 22, which means sunrise might not occur until after 07:45 in western Paraguay in June. Sen. Blanca Ovelar will promote going back to the old -04/-03-with-DST regime. Other possibilities include changing government schedules for schools, banks, etc. to in effect revert the change for some people. Although I do not expect this to affect TZDB in the short run, we should keep an eye on the situation. Nuevo horario divide al Paraguay. El Nacional. 2025-04-29. https://elnacional.com.py/politica/nuevo-horario-divide-paraguay-n84973

1 0

Re: wrong last-modified timestamp in NIST leap-seconds.list
by Paul Eggert April 24, 2025

April 24, 2025

On 2025-04-24 07:04, Judah Levine wrote: > Your comments have adequately addressed the #$ timetamp definition, which is described in the comments to the file. It has been defined this way for as long as I have prepared the file. There has been no leap second for a long time, and that time stamp reflects that fact. The name of the file is chosen in the same way - it changes only when a new leap event is announced, and now points to a time years ago. > I choose the expiration date of the file so that the list of leap seconds in the file will be correct at least until that date. I use IERS Bulletin C, IERS Bulletin A, and other IERS data to derive that date. It includes a prediction of the evolution of UT1-UTC by the IERS, and is more comprehensive than the simple announcement of a leap second in Bulletin C. > Apart from the recent and continuing drama in the environment here, the file has always been updated long before the expiration date arrives - usually when a new Bulletin C is published. The expiration date is intended to be a safety valve if (and only if) there are more serious problems. I regret that I cannot assure you that the current high level of drama is decreasing. > The leap second file is distributed by FTP. The method has very significant difficulties - it is a long and tedious process to update the file, and there are various reports that it is difficult to access. I don't have a choice about this, at least for now. The other alternatives, such as a web page, would be even more difficult to maintain. Thanks for the heads-up. This makes it clear that the NIST vs IERS leap-seconds.list metadata differences are intentional. I installed the attached proposed patch to TZDB to try to document this in a way that TZDB users can easily understand. If it weren't for the problems with FTP and with NIST's lagging expiration timestamps, I'd prefer the NIST metadata as they're less volatile. For now, though, the proposed patch merely changes commentary, rather than changing the default leap-second data source from the IERS back to the NIST (which was the source for many years, until TZDB release 2024a). Perhaps after things have settled down we can help coordinate the IERS and NIST leap-seconds.list files so that they agree not just about data, but also about the last-modified and expiration timestamps. This would help reduce confusion in the future.

2 1

[PATCH] Don't mention boulder.nist.gov
by Collin Funk April 24, 2025

April 24, 2025

The generated leapseconds file mentions the data can be retrieved from ftp.boulder.nist.gov/pub/time/leap-seconds.list, but the domain no longer resolves. From the Internet Archive for boulder.nist.gov it seems like it was a redirect for nist.gov until it was later deleted. The attached patch removes reference to it. Collin [1] https://web.archive.org/web/20180901000000*/boulder.nist.gov

6 13

[PROPOSED 1/6] * Makefile: Modernize comment.
by Paul Eggert April 21, 2025

April 21, 2025

--- Makefile | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/Makefile b/Makefile index 2130582c..502fe2fa 100644 --- a/Makefile +++ b/Makefile @@ -10,10 +10,11 @@ # To affect how this Makefile works, you can run a shell script like this: # # #!/bin/sh -# make CC='gcc -std=gnu23' "$@" +# make CFLAGS='-O2 -DHAVE_GETTEXT=0' "$@" # -# This example script is appropriate for a circa 2024 GNU/Linux system -# where a non-default setting enables this package's optional use of C23. +# This example script is appropriate for a GNU/Linux system +# which needs more optimization than default, and which does not want +# gettext's internationalion of diagnostics. # # Alternatively, you can simply edit this Makefile to tailor the following # macro definitions. -- 2.48.1

2 7

SBOM required for tzdata2025b and tzcode2025b
by Sahil Sharma D April 21, 2025

April 21, 2025

Hi team, Could you please share the SBOM for tzdata2025b and tzcode2025b? Regards, Sahil

4 6

Iran considering reintroducing daylight saving
by Roozbeh Pournader April 11, 2025

April 11, 2025

There's been news today about Iran potentially reintroducing daylight saving. The CEO of Tavanir, the governmental electric power agency, has said that the government is requesting that the parliament let it set daylight saving at its own pleasure, as opposed to the parliament controlling the rules. He estimates that daylight saving would reduce electricity consumption by about 1%, which could be critical since the country is facing energy shortages.

2 1

POSIX.1-2024 link in theory.html
by Max Nikulin April 1, 2025

April 1, 2025

Hi, I have noticed that <https://data.iana.org/time-zones/theory.html> states > As of this writing, the current edition of POSIX is POSIX.1-2024, which > has been published but not yet in HTML form. It seems, it is time to update this paragraph. For precise location in the repository see the attached file. I am unsure if a more precise link https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/V1_chap08.html#ta… should be used. Perhaps some other links should be updated to point to the newer standard revision.

2 3

GNU/Linux distros lagging on yesterday's Paraguay change
by Paul Eggert March 27, 2025

March 27, 2025

Most GNU/Linux distributions, Android, iOS, macOS and Microsoft Windows all have at least version 2025a of TZDB, so properly-updated installations should be working correctly after Paraguay's rule change yesterday. However, Repology reports[1] that the latest stable versions of the following GNU/Linux distributions are still based on TZDB 2024b and thus presumably are misbehaving in Paraguay: Apertis, nixpkgs, OpenWrt, Pardus, Rosa, Trisquel, Ubuntu Of these Ubuntu is best known, and it has several downstream distros that I assume are also affected. So Ubuntu may be the most important laggard for Paraguay. In the list above, I omitted distros like Adélie that use TZDB versions that predate 2024b. I assume these distros are not intended to be up-to-date, are no longer maintained, have distro-specific patches, or aren't tracked accurately by repology. Many other systems also may be out of date for Paraguay; see the first paragraph of the section "The tz database"[2] for a partial list. I haven't tried to track them all. [1]: https://repology.org/project/tzdata/versions [2]: https://data.iana.org/time-zones/tz-link.html#tzdb

3 2

DST end time on Lord Howe Island
by Heitor David Pinto March 27, 2025

March 27, 2025

Hello, In 2001, the database was changed to show the DST start and end times in Lord Howe Island as "2:00" instead of "2:00s". This change only affects the DST end time: if "2:00", it's 2:00 local time, but if "2:00s", it's 2:30 local time. This change was based on a response from the secretary of the island board, who wrote that the DST "changeover" occurred at 2:00 local time. However, reading that comment again, my impression is that he was only referring to the start time, not also the end time. The Standard Time Act of New South Wales says that the summer time period starts and ends at 2:00, but at least in the mainland of New South Wales this is interpreted as 2:00 standard time, so I believe that it should be so for Lord Howe Island as well. All other Australian locations in the database show "2:00s". https://legislation.nsw.gov.au/view/whole/html/inforce/current/act-1987-149 Whether the DST end time is 2:00 or 2:30 local time probably has no practical consequence, as at that time everything is closed on the island and people are asleep. But for precision, I think that it would be useful to confirm this with someone on the island again. Regards, David

2 1

Paraguay Timezone change
by Martin Vuyk March 27, 2025

March 27, 2025

Hi, sorry but I don't have much time to get into the code and submit a patch following your guidelines. The timezone in Paraguay has changed to not have daylight saving time anymore. It is officially GMT-3. This is the official government website: https://www.paraguaytv.gov.py/2024/10/15/paraguay-ya-no-cambiara-su-hora-se… A lot of systems went crazy because some changed the timezone and some didn't. I have some headaches at work already on a Sunday (yay). AFAIK this database is the source of truth for most systems. But I don't know how fast you could change this and it getting pushed to all devices. Please let me know if there is any way I can help fix this ASAP. Kind Regards, Martin Vuyk L.

10 20

Paraguayan Time Zone Error
by Hugo Ortiz March 24, 2025

March 24, 2025

The local goberment of Paraguay stabloshed the GMT-3 time zone for paraguay without no more changes on timezone. Since the 00:00 of 23/03 time zone shifted to GMT-4 on many devices. The paraguayan time zone must stay on GMT-3

2 1

Solicitud de actualización de la zona horaria de Paraguay en la base de datos de IANA
by milciades meza March 24, 2025

March 24, 2025

Estimado equipo de mantenimiento de la base de datos de zonas horarias, Mi nombre es Milciades Meza y me gustaría solicitar una actualización en la base de datos de zonas horarias de IANA en relación con Paraguay. El Gobierno de Paraguay ha decretado oficialmente que el país permanecerá en GMT-3 durante todo el año, eliminando el cambio a GMT-4. Sin embargo, muchos dispositivos electrónicos continúan cambiando automáticamente a GMT-4 debido a que la base de datos de IANA aún mantiene la configuración anterior. Agradeceríamos mucho que puedan actualizar la base de datos para reflejar esta decisión gubernamental y evitar confusiones en los sistemas operativos y dispositivos que dependen de esta información. Para referencia, aquí está el decreto oficial emitido por el Gobierno de Paraguay: [Incluir enlace al decreto o documento oficial si está disponible] Agradezco su tiempo y atención a esta solicitud. Por favor, avísenme si requieren información adicional. Atentamente, Ciudadano de Paraguay Obtener Outlook para Android<https://aka.ms/AAb9ysg>

2 1

[PATCH] No need for America/Coyhaique in zonenow.tab
by Paul Eggert March 23, 2025

March 23, 2025

* zonenow.tab (America/Coyhaique): Remove, since it’s the same as America/Sao_Paolo from now on, given today’s change. --- zonenow.tab | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/zonenow.tab b/zonenow.tab index 6aa41678..093f0a0c 100644 --- a/zonenow.tab +++ b/zonenow.tab @@ -96,8 +96,6 @@ XX +1828-06954 America/Santo_Domingo Atlantic Standard ("AST") - eastern Caribbe # # -04/-03 (Chile DST) XX -3327-07040 America/Santiago most of Chile -# -04/-03 (Chile DST) until 2025-04-06; then -03 -XX -4534-07204 America/Coyhaique Aysén Region # # -04/-03 - AST/ADT (North America DST) XX +4439-06336 America/Halifax Atlantic ("AST/ADT") - Canada; Bermuda @@ -106,7 +104,7 @@ XX +4439-06336 America/Halifax Atlantic ("AST/ADT") - Canada; Bermuda XX +4734-05243 America/St_Johns Newfoundland ("NST/NDT") # # -03 -XX -2332-04637 America/Sao_Paulo eastern South America +XX -2332-04637 America/Sao_Paulo eastern and southern South America # # -03/-02 (North America DST) XX +4703-05620 America/Miquelon St Pierre & Miquelon -- 2.45.2

5 5

[tz-announce] 2025b release of tz code and data available
by Paul Eggert via tz-announce March 22, 2025

March 22, 2025

The 2025b release of the tz code and data is available. This release contains the following changes: Briefly: New zone for Aysén Region in Chile which moves from -04/-03 to -03. Changes to future timestamps Chile's Aysén Region moves from -04/-03 to -03 year-round, joining Magallanes Region. The region will not change its clocks on 2025-04-05 at 24:00, diverging from America/Santiago and creating a new zone America/Coyhaique. (Thanks to Yonathan Dossow.) Model this as a change to standard offset effective 2025-03-20. Changes to past timestamps Iran switched from +04 to +0330 on 1978-11-10 at 24:00, not at year end. (Thanks to Roozbeh Pournader.) Changes to code 'zic -l TIMEZONE -d . -l /some/other/file/system' no longer attempts to create an incorrect symlink, and no longer has a read buffer underflow. (Problem reported by Evgeniy Gorbanev.) Here are links to the release files: https://www.iana.org/time-zones/repository/releases/tzcode2025b.tar.gz https://www.iana.org/time-zones/repository/releases/tzdata2025b.tar.gz https://www.iana.org/time-zones/repository/releases/tzdb-2025b.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 7e1145bfdb9630c127841dc8ce808a937a300938 dated 2025-03-22 13:40:46 -0700 and tagged '2025b' in the development GitHub repository at <https://github.com/eggert/tz>. Here are the SHA-512 checksums for the release files: 19826b12968c10fc4db7e4b07ba782bfb8590eeebaec6f719d74b92a2e642ab817bd72bceff0015ce52a838edfdb00753b3cd87dd84b35abf2606e5bee445f76 tzcode2025b.tar.gz 7d83741f3cae81fac8131994b43c55b6da7328df18b706e5ee40e9b3212bc506e6f8fc90988b18da424ed59eff69bce593f2783b7b5f18eb483a17aeb94258d6 tzdata2025b.tar.gz 4f4afca86645ca5564a9d7d3ddc36e6b07c15c1b87cd4edbbcae72c6be4e6154e4ad1966407a7081237550301f1093af53dd8a486effb95f7cf3e5721db47c8f tzdb-2025b.tar.lz Here are GPG digital signatures for the release files: -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmffIRcACgkQ7ZfpDmKq fjRqwhAAjdPreNSN3pJoZiSwQNVk6oUneEHRlNVDFw1d+DflHG2QW4Cw7wWSRaYi B+yxIV1C61ZwhkAQ1AlscFbpzvHcOtNLEgK5VTwOpgBJ0FsmsEzVUCkGYFtWDpPw qf6ZgdtSrmaPX/V+ceWrRE0oQUjFnlQEO3cwGITlcYlck9YUiQZ+y1gOzPypN+v1 YHuVzoMk4ESTTI/glEJljOQfNcl+GvgnMZRNdZWafpjJ2y68JLofEgemKgJqTu9J IKE6Age2fn2P1lyXlFg1ZTzm11XDIWa8cz37rabNqaybKICeMppSEiIp+BcrMl4p ntQwJyytmm8g2AyGUdHEa9rN97pTag8zzBNmQX/5clcYWIvlp964ul9ptXrBkexN iv+Xi2U1zFg+Wo+ytMyj1q5fhBPTe1rNsnngbrgbGFx0t5h+OOVIPxMCAQiKgGg3 w6V59jgKThJ4EbFaCKV1tN3eThxeSrmCEb6zQEGlS5QKOyTnpQNCEAlJlJ+JyeDo tMbPfCzR9EJjrrMB50qMNK9bXJK3NjsOVicJkv4aruVPfPZ1RrAD6ZDTUk7Yxo9x WHT68C2XIde67N7UIcV4gWgbuZKKagkqPnt+dtn8C/5EML1ANEhtF2is0PqqTXpI ol9XLYC5mnlEQB/F1Bu7EppPCMu7qCaFWQCbvvXaaYjUhiupFPU= =EgQ1 -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmffIRcACgkQ7ZfpDmKq fjS6yw//Wdqj0sipbfTMHAJh3y5065wUkwJhi4cbMbpG1MfJ7HQOeF/ISXBnQo2L RIzpRPswIUweKziBQx5+f+VgViWJTJRTbb2Vk0i1SfnQ6BfeEmqIXwxa87rSeCEk vBeur6mnv3Nc/f9HVvKBqx9ux6FIPWMoQbuDZyNh/GfAvrCp69YkC4miZlo8D1M5 QKoNqLB2B/JTeFVdchVYu9Jxyc2LGsSM9SDTuDDHKQyMyZN/93vJiSzfUMkzW6AF dJif5zWaj2YfrcMFP87IMKH9rAA6XrKNbf+0Xu7AWKpMW6vu30NyMoLQvuo1Gf0g uFxqFTu7fVt6ZzO2cVFuzS/MPj8pufPng88gOHpU34ASID5DB5hf98r7fxmn3jwc aBiecrqpq4F4GEqrBQHGVugFM95iBElvl5kEupO0C/8wqvV7gWoo8Qiaix7b/DE4 zpc4z8wNHntqjeP3Qrv+zX9wfZThYoX/j8UuIVZEhm1o/vHeNn5zBZz55jCQ4KOc Sffl68lWjdLkcS4edsaM1GyPsFnqaFP6FZ95zrhyl/mpsDNJggIaL3RuajMIMCBt othXosBAuBKlv3gqXBIEDaifp2aqBo0YgUUJhcVtyv+advzcUgeppnMUPh0US66R inVSt7pMQ8ubYcDQzDchoVPEay/69SPaRRd3W9unQGCBepjaXGo= =W7AG -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmffIRkACgkQ7ZfpDmKq fjRvqQ//cupgXsGqL6buntdGU8QnbY79jmNbXkuzSbjiAx+uh+sCoS34Rr9eO4Kg mFdVaPqZ704ZvI7yzh6amjpkwdYalmhjVogJ3AIHSlAV69UgedztED18AjQ53/Hj gRqqppZacgUmVO4GqybEb/f4toWfnVi8HuCY++q1WkMgQsAqOE9DIJlJOTK5BAEo Iy6+vAigXc7LyveyBP/2yOOoPTkWTRTURfXHXgQxgKuGtDJHnp12j2MPhzag5s64 KrInD6ZB1ZcpDw9BpDd+LmB1gZizwShadXbiMOi8ROC6JwR8oafZJq3rwonSkJLH kMg6VUQr3cQmu8Zd5s9yYpZmx4rMBR+9Hsz5bn0cBLSe478LtmoKI6vI37mZ048S PRTwlHnXi1/RuxovhusPiaoAf3VUN8IxhL2V4NV9D2Pn+iu3Fhj35BlM3XOn1RpH 3K3qi/Wr4XRX6jlPLQ42opBnkKorL21+Tz21+yHDOXxbF+9fYmZOaMaZwl3AjX66 QbWEN8FG+2UEOHVSyxjLKru97TV+RXSo/A1IBwTHALeaiLSc+V1zSTMMrAQVSDPm Rn1VXPc9Jff00LEM0CElS4X719d/0a0Knbs9OjIbp2bmZEun8zTGHOPEtJ8PWrc6 ficDmgynqV89laKtZ7VsUoMgHEKv7dCs1HdFBYQ5qvWW/JiKZhU= =qJJK -----END PGP SIGNATURE-----

1 0

Adjust to coverage of TZ America/Punta_Arenas
by Eduardo Romero Urra March 22, 2025

March 22, 2025

Dear Paul, The government of Chile announce adjust of coverage of Time Zone "Región de Magallanes y la Antártica Chilena" , now extend their coverage to Region "Región de Aysén del General Carlos Ibáñez del Campo," . This region coverages the following Cities: Coyhaique , Puerto Aysen and Cochrane . This area keeps all the year on UTC -03 Timezone . I've attach the link https://www.diariooficial.interior.gob.cl/publicaciones/2025/03/20/44104/01… Best regards ━━━━━━━━ Eduardo Romero Urra Asesor de Sistemas División de Redes y Seguridad Informática +56224863218 Ministerio del Interior y Seguridad Pública Gobierno de Chile CONFIDENCIALIDAD Y USO EXCLUSIVO: La información contenida en este mensaje y/o en los archivos adjuntos son de carácter confidencial y está destinada al uso exclusivo del emisor y/o de la persona o entidad a quien va dirigida, y por lo mismo pueden ser consultados y revisados por la entidad emisora o propietaria de los sistemas desde donde fueron enviados.- Si usted no es el destinatario, cualquier almacenamiento, divulgación, distribución o copia de esta información está estrictamente prohibida y sancionada por la ley. Si recibió este mensaje por error, por favor infórmenos inmediatamente respondiendo este mismo mensaje y borre éste y todos los archivos adjuntos. Considerando que no existe certidumbre de que el presente mensaje no será modificado como resultado de su transmisión por correo electrónico, el emisor original no será responsable si el contenido del mismo ha sido modificado. Ministerio del Interior y Seguridad Publica<https://www.interior.gob.cl>

2 1

[PROPOSED] northamerica: mention Daylight Bill
by Paul Eggert March 20, 2025

March 20, 2025

--- northamerica | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/northamerica b/northamerica index 8d356aa0..20b47b48 100644 --- a/northamerica +++ b/northamerica @@ -1611,6 +1611,15 @@ Zone America/Moncton -4:19:08 - LMT 1883 Dec 9 # For more on Orillia, see: Daubs K. Bold attempt at daylight saving # time became a comic failure in Orillia. Toronto Star 2017-07-08. # https://www.thestar.com/news/insight/2017/07/08/bold-attempt-at-daylight-sa… +# From Paul Eggert (2025-03-20): +# Also see the 1912-06-17 front page of The Evening Sunbeam, +# reproduced in: Richardson M. "Daylight saving was a confusing +# time in Orillia" in the 2025-03-15 Orillia Matters. Richardson writes, +# "The first Sunday after the switch was made, [DST proponent and +# Orillia mayor William Sword] Frost walked into church an hour late. +# This became a symbol of the downfall of daylight saving in Orillia." +# The mayor became known as "Daylight Bill". +# https://www.orilliamatters.com/local-news/column-daylight-saving-was-a-conf… # From Mark Brader (2010-03-06): # -- 2.45.2

1 0