On Feb 24, 2026, at 9:59 PM, Paul Eggert via tz <tz@iana.org> wrote:
On 2026-02-24 15:37, Samuel Wat wrote:
As for the logistics of where Makivvik is at with making it officially with TZDB, that's something I can't speak to.
TZDB doesn't have official status in that sense.
Yes. Governments are *not* obliged by any international treaty or other such binding document to get the TZDB to sign off on time changes. It would be helpful if governments were to notify us of time zone changes as soon as they're officially decreed or signed into law - and preferably as much before they take effect as possible - so that the TZDB project can prepare and publish updates as soon as possible, so that all of the TZDB's downstream users can send out updates. As the "Coordination with governments" section of the main page - https://data.iana.org/time-zones/tz-link.html#coordinating - says: 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 as described in "Changes to the tz database". Do this 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. ("How Time Zones Are Coordinated" is at https://www.icann.org/en/blogs/details/how-time-zones-are-coordinated-13-03-.... "On the Timing of Time Zone Changes" is at https://codeofmatt.com/on-the-timing-of-time-zone-changes/.) So "making it officially with TZDB" really means "helping the TZDB project release updated an updated version of the TZDB containing the change, by notifying them as soon as the change is official". Doing so is not an official process, it's just a helpful step. (There are probably other bodies for whom those notifications would be useful.)