Keeping timezone data current

Allgemein, DateTime, DevOps,

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.

Bringing “The PHP Community” together

Allgemein

Yesterday the PHPVerse online-conference was taking place. For reasons unrelated to what I am writing about here I didn’t participate. And let me be 100% clear: This is a personal opinion that is based on observations around the conference, not on the content itself!

What is PHPVerse?

PHPVerse is an online conference organized by Jetbrains and free to attend for everyone registered.

The idea is to connect different parts of the splitted PHP-Community which I endorse! So for this edition there were people from the Symfony-, WordPress-, Laravel- and the Drupal-Community doing sessions along with people vocal on the internals mailinglist, maintaining the PHP package manager and from the PHP Foundation.

But this is not about the content that these people brought. What hit me were three fundamental things about “The Community” that in my opinion need to be addressed differently and why I am increasingly weary of such events.

1. The Community

What community are we talking about here. Or let me ask this question slightly different: Which parts of “The Community” are we **not** reaching?

I realised that when I wanted to toot about the event: It doesn’t have an account on mastodon…

🤯

Yes! I know! There are several other social networks out there.

And on the main website of the event there are several social networks showing up right at the top: X, Facebook, LinkedIn and BlueSky.

Given that there is such a thing as a PHP-Community Mastodon server (at https://phpc.social) where an integral part of the PHP-Community is “hanging out” it seems like an odd choice to not at least include that in that list.

I understand that a “Free” event still needs to pay off for someone and that it is far easier to track “interactions” on walled-garden “social” networks. But if you want to do something **for** the community without a vital part **off** the community, that seems like “Doing it wrong™”

2. The time

Interesting was also the timing. When doing an online event, it is really hard to please everyone. Especially when you want to do an event in “only” 8 hours. Due to the nature of the world the PHP-Community is online almost 24h a day. It is spanning from New-Zealand, Australia and Japan on the east side all the way over to the Americas with Alaska and Hawaii reaching out furthest west. (Yes! There are some people even nearer to the date-line, I know!).

The event was set to happen from 11:00 UTC to 16:30 UTC. Which means 23:00 through 4:30 in Auckland. That requires some commitment to follow this event from there. Even as far west as the Indian Subcontinent – where the event took place from 16:30 through 22:00 that requires some commitment to follow that late into the evening.

When I realized that I immediately had to think about this tweet from 2021:

Only that this time event Japan, Australia and New Zealand are missing.

Again: “The Community” is actually only a part of the community that we are talking about.

3. The people

And then I stumbled upon a toot from Pauline Vos:

Just saw the trailer for the PHP documentary shown at PHPVerse…

ZERO women? Are you serious? 5 women (including at least 3 past or present core developers that I know of, and the executive director) on the @thephpf , and the story of PHP includes ZERO women?

Not to mention those prominent in the community that aren’t part of the Foundation itself. You can’t be serious.

Yes! There are not that many women around in the PHP Community. One might think. But actually there are. But with this kind of marketing, that amount will – to put it mildly – not increase.

Again: A huge part of the community not only lost but actually alienated.

Takeaway

To summarize: Time, Interaction and trailer-Content indicate that “The Community” the PHPVerse is talking about, is the European and North-American male dominated part that is still hanging out on the BigCorporation networks.

That is not the PHP Community I know and that I consider myself a part of. On the contrary! That seems to be the image that the PHP Community needs to get away of to actually become a world-wide, welcoming, vibrant, and healthy community.

Oh! And before you start responding with reasons why something doesn’t work or can’t be done differently: Think about this:

Where there’s a will, there’s a way; where there isn’t, there’s an excuse.

Code-Coverage with PCOV in a mono-repo

Development, DevOps, PHP, , ,

Today I finally managed to find and fix an issue that we had for some time with Code-Coverage generation with PCOV in github actions.

To give you a bit of background, imagine a project that uses 2 separate folders where one contains the business-logic and one contains the framework-related code. The framework-related part contains a lot of integration and end-to-end test that – of course – also use and therefore test the business-logic.

Every PullRequest runs the tests both from the bunsiness-logic part as well as from the framework-related part. And to give the developers feedback how well the changed code is covered with tests we collect coverage data and generate a patch-coverage report. I wrote about that some time back. So we now get a comment each in the PR that contains the untested lines in the business-logic related part and the framework-related part respectively.

That worked flawlessly for the business-logic related part as those were mostly unit-tests that do not rely upon the framework-related code.

The framework-related part though didn’t work that great. It always showed the business-logic related parts as untested even though I knew they were tested.

Continue reading Code-Coverage with PCOV in a mono-repo →

Property-Hooks for the win

Allgemein, Development, PHP, , ,

Property-Hooks were one of the really hot topics of last years PHP8.4 release. And I do have very strong opinions on them. They were and probably still are extremely hyped for something that in my personal opinion should be a very niche thing. In new projects you shouldn’t really need them.

But just today I had one of those situations where they helped me combine legacy code with new functionality.

The starting position

I am working on a project where we are using PDO and especially PDO::FETCH_CLASS to create Objects from our database-content.

So the code looks something like this:

function getAllFoos() : array
{
    $stmt = $this->executePdoQuery(<<<SQL
        SELECT * FROM table
        SQL);
    $stmt->setFetchMode(PDO::FETCH_CLASS, Foo::class);

    return $stmt->fetchAll();
}

Foo looks something like this:

final class Foo 
{
    public string a;
    public string b;
}

And the database-table looks something like this:

CREATE TABLE foo (
    a VARCHAR(20),
    b VARCHAR(20),
)

Everything worked as expected and calling getAllFoos got me a list of Foo-objects.

So Far so good.

Now I wanted to add a new field to the Foo-object and that should contain an Enum. Easy peasy.

final class Foo 
{
    public string a;
    public string b;
    private Status $status;
}

enum Status: string {
    case Open = 'open';
    case Closed = 'closed';
}

Now I need to update the database

ALTER TABLE foo ADD COLUMN `status` VARCHAR(10) NOT NULL DEFAULT 'open';

That’s it!

When testing that though I found that it wasn’t because now everything blew up when calling getAllFoos ….

What happened?

Well, as expected the fetchAll tried to hydrate the values of the Foo object wth the values from the DB. But the DB contains a string whereas the Foo object expects the respective enum.

There is no out of the box solution to this. PDO has no idea how to convert this database-value into something the object understands (it could infer the expected enum-type from the type-hint but that can get out of hand rather quickly when it’s not an enum bot any other object that doesn’t have a ::from method or…)

Property Hooks to the rescue.

So I had to find my own way around this. And here property hooks are awesome when one has to adapt to legacy code.

So this is what my Foo class now looks like

final class Foo 
{
    public string a;
    public string b;
    private Status $status {
        set(string|Status $value) {
            if (is_string($value)) {
                $value = Status::from($value);
            }
            
            $this->status = $value;
        }
    }
}

Works like a charm now!

Content-Negotiation

Allgemein, Development

A few years back I had a great live-experience regarding failed Content-Negotiation. I was sitting in Montreal in a restaurant waiting for the waiter. Once they came they asked me something in french and I immediately told them that I don’t understand french and whether we could speak english. We could. So I got a menu (in english and french) and a few minutes later they came back to take my order. And they talked to me – again – in french. So we had to go through the whole dance again.

What does that have to do with Content-Negotiation? Well: We did negotiate that we would communicate in english. Comming back to me with some language that we already had established I can’t understand doesn’t make sense. And I might just not understand what they want.

Continue reading Content-Negotiation →