On 1st of November 2026 several canadian provinces will not fall back to standard time from DST. They decided at several different points in time that they will not do so.

British Columbia did so in March already whereas Alberta decided so in June, the Northwest Territories in August and Manitoba in September.

As is the usual process shortly after the decission was made, there was a new version of the timezone-database released so that the information is available only with a short delay to everyone that needs it.

Who needs that? Well… That database is on every computer whether Linux, Windows or MacOS, on every mobile device from Android to iOS and on every Smartwatch out there. In every GPS in your car, yacht or plane. More or less in any electronic device that keeps track of time. So yes! Your smart-fridge might also be running it.

I was now recently challenged to do some updates of data that was converted wrongly based on the information in the old versions of the database and to convert it to the new version of the database (I have written why it is a bad idea to do that previously)

Only to end up in its own kind of hell.

It all started with something that I realized quite some time back: The International Components for Internationalization – in Short ICU – ship with their own version of the timezone database. And the ICU version in some linux-distributions is notorioulsy outdated. And due to the ICU version being outdated, the timezone-data is also outdated. Not by a month or one or two versions. We are talking years. The probably still widely used Ubuntu LTS version 24.04 – codename Noble Numbat – ships with ICU version 74.2 – released in December 2023. And that ships with the timezone database 2023c from March 2023.

When I realized that, I started digging into how to update the ICU version so that PHP applications can actually get the latest ICU as well as the latest timezone-data.

And then I had to dig into that deeper. And I figured out that it is much easier to do the updates for the ICU timezone-data (not the update of the ICU package itself though! Just the timezone-data!) by installing a package called tzdata-icu!

Install that on your ubuntu machine and you are up-to-date! (Sidenote: Why that package is not automatically installed when installing the ICU package is totally beyond me! Why would one want to use the ICU package that is aweseome for date-formatting but use the outdated timezone information for that?)

Or so I thought…

It turned out that the release of the timezone-database does not mean that there will be a corresponding release of the tzdata-package (or the tzdata-icu package) in Ubuntu. That can take a while. And when it is available it is first available in the proposed channel and then some days later moves to the update channel…

It looked like the tzdata package of Ubuntu for the tzdb release 2026b was released in the update channel in July. Remember: The release of the tzdb was in March.

So. Looks like everything is solved.

Finally I had everything up-to-date. Slightly delayed due to the package-delay, but still!

Along came GithubActions.

Where I installed php running on an Ubuntu system.

And suddenly all my tests that require the latest timezone data failed. Looks like the Ubuntu runner used outdated data

So then… Luckily Derick Rethans maintains the timezonedb package on pecl and that is usually available for PHP with a very short delay! So I installed setup-php with extension: timezonedb and everything was good. (I actually had to use timezonedb-2026.5 but that was due to a bug that should be fixed with the next release!)

What did I learn from this:

• Just because ther eis a new release of the IANA timezone database doesn’T mean that there is immediately a new release for my distribution
• The ICU extension uses its own timezone database. And by default a really old one
• The timezonedb extension for PHP is usually really up-to-date and a safe way to update the timezones for PHP.
• Updating the timezones for ICU can be really easy depending on the distro
• The challenge is not creating code that works correctly with timezones. It’s getting the correct data on time.