Issue with localconfig.timeZone

[fritzmg]

Affected version(s)

4.13, 5.3

Description

Typically you configure your localconfig.timeZone setting (either via config/config.yaml or system/config/localconfig.php/System settings in the back end) to the time zone the principal business of the website is in, e.g. Europe/Vienna - especially if the server's PHP default is something else (e.g. the default value UTC).

This setting will then - and only then! - be applied during runtime when the ContaoFramework is booted. This however means that any code in your application that does not need the ContaoFramework to be booted runs a in a different timezone setting.

This can cause issues with symfony/messenger for example:

Let's say the server's date.timezone setting was not changed from its default UTC value, but you have set the localconfig.timeZone setting to Europe/Vienna. If, during a regular Contao request, where the ContaoFramework is booted, you now send a message to the message bus, Symfony's default doctrine message queue will store the message's delivery time as a datetime object, which will then contain a date time string relative to the Europe/Vienna timezone.

However, if you then consume these messages on the command line where the ContaoFramework does not boot - these messages will now not be consumed for an hour, as the message's delivery time is now 1 hour in the future.

As a workaround can make sure that all your console commands run in the "correct" timezone, regardless of the PHP CLI config - e.g.

/usr/bin/php8.3 -ddate.timezone="Europe/Vienna" vendor/bin/contao-console …

However, this can be easily missed (and leave yourself befuddled as to why your messages aren't consumed even though they are so obviously there ready to be consumed 😁).

[ausi]

I think the correct way forward is to remove the localconfig.timeZone setting as this should be configured in the php.ini of your webspace.

However, as this is not easily possible to do at every hosting provider, it might make sense to load a php.ini specific to the webspace in our Kernel?

But we could only load INI_USER and INI_ALL settings, so things like max_input_vars, upload_max_filesize or post_max_size would still not be able to be changed with such a feature. This might make it even more confusing.

Maybe instead we should just add an APP_TIMEZONE env variable to replace the localconfig.timeZone?

[ausi]

Or maybe we should suggest our users to set the timezone via php_value in .htaccess for Apache or using a .user.ini file for php-fpm?

But in this case we’d need to load these files from the command line too, which is not a great thing to do for the .htaccess case 🙈

[aschempp]

The advantage of APP_TIMEZONE would also be that it could be configured through the Contao Manager. It must always be loaded from the ContaoKernel then in my opinion, not just when the framework is bootet.