@tsteur opened this Issue on September 6th 2022 Member

In PHP 8.0.16 the timezone for Ukraine is Europe/Kiev (php -r "var_export(DateTimeZone::listIdentifiers(DateTimeZone::PER_COUNTRY, 'UA'));" | grep "Europe/Kiev") but in PHP 8.0.20 it is Europe/Kyiv. That means if you previously were on Kiev timezone, and then upgrade to a newer PHP version, then Matomo no longer considers it as valid. That can be an issue when the site or default timezone is configured accordingly.

We ran into this issue on the cloud.

See also https://twitter.com/derickr/status/1557755162281795585

@sgiehl commented on September 6th 2022 Member

@tsteur There has been various changes to the timezones across PHP versions over time.
The question is how we should solve that. I guess the old names can still be used within the code, but won't be in the selection of available timezones anymore. So changing a site might be an issue. Or are there also issues while archiving or similar?

@tsteur commented on September 6th 2022 Member

I haven't tested it but I assume it may cause issues when archiving, or when trying to edit and then saving a site there may be issues. I've done basic test to set it to a different zone in the site settings and then it was showing me Algeria as it's the first entry. Meaning as soon as you save the site it will change the timezone without you knowing. Same might be for global measurable settings. Same may or may not be for archiving.

@sgiehl commented on September 9th 2022 Member

@tsteur That issue might actually not only be related to the PHP version. A couple of linux distributions are patching the timezone support to use the systems timezone database instead. My Ubuntu box for example already uses Europe/Kyiv with PHP 7.2.

Nevertheless using old timezone names shouldn't be an issue, as PHP should still handle them correctly.
So as you said, the main problem is, that the time zone selector would automatically select the first available timezone when a old timezone was configured.
What would be the expected behavior in that case? We could e.g. add a configured timezone to the selection list if it isn't available anymore, so it would at least not be changed automatically.
In addition we could maybe trigger a notice to show that the timezone is outdated.
Or what would you suggest here?

@tsteur commented on September 11th 2022 Member

So as you said, the main problem is, that the time zone selector would automatically select the first available timezone when a old timezone was configured.

Possible that also archived reports (looking at wrong start/end hour) and also our reports "Visits per hour in the site's timezone" become incorrect. Not sure what happens there when an unused timezone is used.

I don't have any specific thoughts/ideas on expected behaviour. I'd maybe search first if we can find some list of timezone changes over the years and see if we can maybe somehow build a map for changed timezones to map an older one to a newer one but this of course would need to be maintained. There might be better solutions. Maybe there are some projects/libs around this problem etc.

Powered by GitHub Issue Mirror