Besides laptop and desktop systems whose updates may take some weeks; server updates, especially LTS releases, may take months due to slower downstream update processes, plus inhouse corporate testing processes; tablet and phone mobile devices may take weeks or months depending on their priority with the vendor, the telco, and the size of the market in the country for the device; older, cheaper devices (like mine) may only get annual updates, if they are still supported on any upgrade schedule by the telco or vendor. Governments like to think external orgs can provide updates in days, but it normally takes weeks for any official updates, and for older releases months, or never, so may be DIY, by finding something on the internet and trying it! Especially so if the country in question has a population (AKA market) less than some cities, or for some island nations smaller than large towns! As a workaround fallback, users may select the zone below (extracted from zonenow.tab) until updates are made available for their system: -03 America/Sao_Paulo eastern and southern South America -- 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 à retrancher but when there is no more to cut -- Antoine de Saint-Exupéry On 2025-03-24 12:32, Martin Vuyk via tz wrote:

Hi Tim, thanks a lot for the information! good to know there are people who are so much on the lookout for these changes!

...

Unfortunately, downstream maintainers can often be slow to pick up on these changes.  We suggest working with the maintainers of these systems to pick up and distribute our latest release to your users.

It seems this is totally a thing about version release schedules. It was way too soon to declare a change like that on my country's part.

Thanks a lot and your work maintaining this is highly appreciated :)

Cheers, Martin Vuyk L.

El lun, 24 mar 2025 a la(s) 2:57 p.m., Tim Parenti escribió:

On Mon, 24 Mar 2025 at 13:38, Martin Vuyk via tz <tz@iana.org <mailto:tz@iana.org>> wrote:

A lot of systems went crazy [in Paraguay] because some changed the timezone [this past Saturday evening] 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.

All— The recent change for Paraguay (staying on -03 and no longer falling back to -04 from 2025-03-22 24:00) was made to our development repository in the following commits dated 2024-10-05 and 2024-10-15: https://github.com/eggert/tz/commit/636e6f983bca35e6f945e092ffdc315ae3e5dd9e <https://github.com/eggert/tz/commit/636e6f983bca35e6f945e092ffdc315ae3e5dd9e> https://github.com/eggert/tz/commit/486e1e890e68d52f9236b2b354484463f57ec692 <https://github.com/eggert/tz/commit/486e1e890e68d52f9236b2b354484463f57ec692>

These changes were included in version 2025a of tzdata, released 2025-01-16, and remain available in version 2025b released this past weekend.

Unfortunately, downstream maintainers can often be slow to pick up on these changes.  We suggest working with the maintainers of these systems to pick up and distribute our latest release to your users.

Unfortunately, the processing time at IANA presented a challenge this time. The period from the October 2024 development repository update to the January 2025 deployment version, impacting the March rule change, was longer than ideal. I remain a strong advocate for the volunteer efforts that drive our community. However, this situation highlights a potential area for improvement. Best regards, Carlos On Mon, Mar 24, 2025 at 11:14 PM Tom Lane via tz <tz@iana.org> wrote:

Brian Inglis via tz <tz@iana.org> writes:

...

Governments like to think external orgs can provide updates in days,

I suspect that the officials issuing these sorts of orders haven't really thought about implementation at all. Their mental model of what needs to happen is probably still "everyone will manually set their mechanical wristwatches forward an hour, job done". In other spheres governments are well aware of the need for lead time, but it seems there's a blind spot on this point.

regards, tom lane

On 3/25/25 11:40, Brian Inglis via tz wrote:

They have to provide substantial notice to IATA about time changes, and are fined millions if they make late changes, ...

What entity imposes such a fine? -- gil

On Mar 25, 2025, at 14:50, Brian Inglis via tz <tz@iana.org> wrote:

On 2025-03-25 11:54, Paul Gilmartin via tz wrote:

...

On 3/25/25 11:40, Brian Inglis via tz wrote:

...

They have to provide substantial notice to IATA about time changes, and are fined millions if they make late changes, ... What entity imposes such a fine?

See late cancellation by Egypt in 2016 where they paid $8M to IATA:

https://english.ahram.org.eg/NewsContent/1/64/232511/Egypt/Politics-/Travell...

https://codeofmatt.com/time-zone-chaos-inevitable-in-egypt/

also discussion here on list.

Wow. IANAL, but I /think/ there's a pretty big difference between the IATA and the IANA, though. IATA certification of a country's airports is a regulatory affair. They require fees and dues of its members. There are rules to follow and they are spelled out. If one does something that causes the IATA certificates to lapse or be revoked/suspended, then commercial air carriers will stop using the airports because, I am told, insurance will stop covering those flights. I imagine that's just the start of a list of pretty undesirable effects such as happening would have. IANA is not that kind of entity. From what I can tell, neither is PTI or even ICANN for that matter. One does not enter into any kind of contractual or enforceable agreement, certainly not as far as timezone-related business is concerned. In this regard, IANA TZDB is more of a service; a clearinghouse of information that is /de facto/ canonical for computing-related timezone information. I think a more realistic strategy would be to make the technical process of implementing timezone adjustments more visible and understandable. It would include a clearer framework for government representatives to *proactively* inform the TZDB group and coordinators of any pending changes once the relevant law/edict/whatever has been finalized. There's a lot that would go into such an effort and would be impossible to summarize succinctly here. The current IANA TZDB website doesn't really say much beyond "we exist" which, I feel, doesn't help when it comes to expediently getting changes published, integrated into any given OS's patch cycle, distributed, and applied. /dale

On 3/25/25 13:41, Dale Ghent via tz wrote:

I think a more realistic strategy would be to make the technical process of implementing timezone adjustments more visible and understandable. It would include a clearer framework for government representatives.... The current IANA TZDB website doesn't really say much beyond "we exist"

Currently, the website[1] says the following about this. Suggestions for improving the wording are welcome. ----- Coordinating with governments and distributors As discussed in "How Time Zones Are Coordinated", the time zone database relies on collaboration among governments, the time zone database volunteer community, and data distributors downstream. If your government plans to change its time zone boundaries or daylight saving rules, please send email to tz@iana.org well in advance, as this will lessen confusion and will coordinate updates to many cell phones, computers, and other devices around the world. In your email, please cite the legislation or regulation that specifies the change, so that it can be checked for details such as the exact times when clock transitions occur. It is OK if a rule change is planned to affect clocks far into the future, as a long-planned change can easily be reverted or otherwise altered with a year's notice before the change would have affected clocks. There is no fixed schedule for tzdb releases. However, typically a release occurs every few months. Many downstream timezone data distributors wait for a tzdb release before they produce an update to time zone behavior in consumer devices and software products. After a release, various parties must integrate, test, and roll out an update before end users see changes. These updates can be expensive, for both the quality assurance process and the overall cost of shipping and installing updates to each device's copy of tzdb. Updates may be batched with other updates and may take substantial time to reach end users after a release. Older devices may no longer be supported and thus may never be updated, which means they will continue to use out-of-date rules. For these reasons any rule change should be promulgated at least a year before it affects how clocks operate; otherwise, there is a good chance that many clocks will be wrong due to delays in propagating updates, and that residents will be confused or even actively resist the change. The shorter the notice, the more likely clock problems will arise; see "On the Timing of Time Zone Changes" for examples. [1]: https://data.iana.org/time-zones/tz-link.html#coordinating

While I agree that the two month difference in a release likely wouldn't have made a difference, what is the disadvantage of having more frequent releases? Jacob Pratt On Tue, Mar 25, 2025 at 7:05 PM Paul Eggert via tz <tz@iana.org> wrote:

On 3/25/25 05:22, Carlos Raúl Perasso via tz wrote:

...

The period from the October 2024 development repository update to the January 2025 deployment version, impacting the March rule change, was longer than ideal.

I remain a strong advocate for the volunteer efforts that drive our community. However, this situation highlights a potential area for improvement.

It's not hard to prepare a new release and hindsight tells us that an October TZDB release would have been better. However, we delayed because we thought that there was a good chance the Philippines would announce a change that would take effect in January. We did a new TZDB release when it became clear this wouldn't happen.

There is a tension between releasing early and delaying a bit, a tension that has little to do with Tim's and my maintenance effort. We could release more quickly in the future, though this will entail more downstream effort and mistakes.

For what it's worth, my guess is that the recent glitches in Paraguay wouldn't have been much less numerous even if we had released TZDB in October, because the main bottleneck is that people don't install updates. It'd be hard to prove this one way or the other, though.

On Mar 25, 2025, at 19:05, Paul Eggert via tz <tz@iana.org> wrote:

There is a tension between releasing early and delaying a bit, a tension that has little to do with Tim's and my maintenance effort. We could release more quickly in the future, though this will entail more downstream effort and mistakes.

Would it make sense to decouple the "political" data of the timezones themselves from the technical tooling? This would permit what are essentially database updates to be distributed on their own, perhaps more aggressive, cadence. It would avoid any case of being held back due to in-flight or "too fresh" maintenance work on the tools. It is entirely possible that I could be overlooking a reason as to why they are tied together into a single entity. Coming from an OS packaging and maintenance background, I understand the desire to batch up changes as a courtesy to the immediate downstream consumers of tzdb. But I'm of the opinion that the decision of whether to accumulate changes or release them immediately as updates/patches should rest with those consumers. As the origin of this data, I think it would be completely fine for tzdb to quickly release new versions as timezone changes become known and are verified as legitimate. I mentioned decoupling the database from the tools as a way to further facilitate this. This way, if an OS or app maintainer/vendor is asked by a customer/user if they have prepared updates for a particular upcoming timezone change of interest, the maintainer/vendor has the ability to quickly render the necessary update rather than waiting on the tzdb maintainer to kick out an official update that they can then use. Because no one can control when timezone changes happen and how much lead-time there is between the legislation being made and the change going into effect, any delay might mean vendors might have to issue an 11th hour update that contains the new timezone data. I thought I'd mention that I really like the tzdb changelog. The details it contains are clear and often educational.

For what it's worth, my guess is that the recent glitches in Paraguay wouldn't have been much less numerous even if we had released TZDB in October, because the main bottleneck is that people don't install updates. It'd be hard to prove this one way or the other, though.

To me, this is just more of a reason to get the info available as soon as possible after it's known and verified. Put the decision of waiting for more changes (or not) on the downstream consumers. I imagine the cadence of timezone changes might pick up over the next years - if it hasn't already - as more locales seem to be weighing whether to dispense with DST. The tzdb maintainers can advise if there *might* be additional changes in the near future, such as in the Paraguay/Philippines situation you mention. But part of an OS maintainer's job is to weigh and schedule updates based on their user's needs, and their own release cadence and patching policies. If a user is demanding updates because they run systems in an affected locale, I would like to be able to issue that update in short order rather than wait on upstream to decide to release them. /dale

Date: Wed, 26 Mar 2025 10:38:28 -0400 From: Dale Ghent via tz <tz@iana.org> Message-ID: <6ACCA17A-0681-4C8F-B17B-30D7B2B70AC5@elemental.org> | Would it make sense to decouple the "political" data of the timezones | themselves from the technical tooling? You're totally misunderstanding the problem. The tzcode part is almost 100% irrelevant in all of this, updates to that are rarely all that important, and no-one much cares when downstream distributions incorporate them, typically there is a delay of several years between when some new feature there is added, and when it might start being used. What needs to be tested and validated after updates is: | This would permit what are essentially database updates that part, that's what controls everything related to releases (it has been quite a long time since there was a release triggered, or delayed, by any code update). | to be distributed on their own, perhaps more aggressive, cadence. | It would avoid any case of being held back due to in-flight | or "too fresh" maintenance work on the tools. That doesn't happen - if something in that area wasn't considered ready, it would just be moved aside until next time. | It is entirely possible that I could be overlooking a reason as | to why they are tied together into a single entity. Once upon a time they weren't, each happened on its own when needed (that was when more serious code changing was more common). I suspect it is largely a matter of convenience for everyone, so that there is a common version number, and it is easy to tell when something has been missed (it used to be that the tzXXXNNNNa type labels would move from a to b for a data update, then to c, and perhaps d for code updates, then the next data update might be e ... all a bit of a mess (though that wasn't common, and is all long past). But this absolutely is not the issue, or any part of it, so it is irrelevant. | But I'm of the opinion that the decision of whether to accumulate | changes or release them immediately as updates/patches should rest | with those consumers. It is all in publicly available git as I understand it, anyone able and willing to use git (which excludes me, I hate it) can fetch and update any time they want to. Few do. | This way, if an OS or app maintainer/vendor is asked by a | customer/user if they have prepared updates for a particular | upcoming timezone change of interest, the maintainer/vendor has | the ability to quickly render the necessary update rather than | waiting on the tzdb maintainer to kick out an official update They could do that now, they just don't - they (and probably for reasonable reasons) prefer to wait for the releases. It takes a lot of research to actually determine when some random change being made somewhere in the world is truly happening, and not just someone's random idea of what they would like (that someone perhaps being of some importance in the relevant region) who is proclaiming that it is going to happen. Then doesn't. | Because no one can control when timezone changes happen and how | much lead-time there is between the legislation being made and the | change going into effect, You mean none of us can control it, and that's right - but the people making that legislation (sometimes it is just some kind of executive order) certainly can. They're the ones who believe they can order the clocks to change tomorrow, and it will simply happen, because they have decreed it. If you (anyone) has been affected by one of these hasty changes being made you should be making noise in whatever way is appropriate and complaining publicly about the incompetence of whoever made the change - embarrass them, that way they might not do it again. Nb: for this, not complaining about the change that was made (whether you agree with it or not) but purely with respect to the lead time allowed. Those administrations who have some kind of real idea of what is involved typically try to make changes, and announce them, about 18 months before any change will affect anything. That gives everyone plenty of time to update all kinds of things - some of which tend to be printed and distributed (and yes, people do still print this stuff) once a year or so. kre

On 3/26/25 13:40, Dale Ghent via tz wrote:

I have two options:

And you make good points. However, there is a third option, which I mentioned in [1]. It generates a version number that indicates the "in-between" nature of whatever commit is used and this should mollify (at least to some extent) more astute customers. For example, with TZDB commit 486e1e890e68d52f9236b2b354484463f57ec692, which is immediately after TZDB's Paraguay changes in October, the third option generates TZDB version 2024b-10-g486e1e8, a version number that sufficiently-astute customers can comprehend. There is no perfect solution here. Releases are to some extent arbitrary and there is no universal agreement on when they should happen or what should be in them. Some downstream users would prefer releases to be rapid and often; others, not so much. Downstream users that prefer more-rapid releases than the "official" ones can use this third option. [1]: https://lists.iana.org/hyperkitty/list/tz@iana.org/message/334HGRQ7KWM3JBRVP...