Add PHP time zone check to Site Health

[Rarst]

WordPress core is hardcoded to set default PHP time zone to UTC during load. Historically a lot of Date/Time core code relies on this assumption.

So using date_default_timezone_set() in WP runtime causes widespread and obscure issues.

While long term plan is to make core code not rely on this state and be insensitive to it changing, it is likely we will keep UTC time zone forever or risk breaking extension code out in the wild.

Following suggestion in #48623 I concur this makes sense as health check, if date_default_timezone_get() results in anything other than UTC.

I would like to get this into 5.3.1, since 5.3 shipped a lot of changes to make this more robust but inadvertently caused issues from changed time zone to manifest in a new and different ways.

Will work on a patch, if I can make a quick sense of how to add a new test. :)

[Clorith]

We implemented a timezone checker, to check for UTC-N formats, to the plugin not long ago, it unfortunately just fell a bit into the shade as we discovered some false positives with database checks at the same time. I've attached a patch with what is in the plugin, the text may need some adjustments?

[Rarst]

That's a different issue, I am not talking about WordPress-level time zone configuration, but PHP-level one.

[Rarst]

Patch added. Wording is tricky since this is (as above :) a confusing distinction between PHP timezone settings and WordPress timezone settings.

I chose to specifically not show valid and invalid values, so that user is not confused about needing to go into their WordPress settings and do something there. Instead I specifically pointed out date_default_timezone_set() function call as the problem.

Not sure about guidance on badge color, set it to red on failure since stuff is prettty critical right about now, for people who have this broken.

[TimothyBlynJacobs]

Maybe removing the word "setting" entirely would help clarify? I don't think just it being the "PHP setting" will disambiguate it enough from the WordPress timezone setting. Setting seems like something they'd be able to adjust themselves in the UI.

[SergeyBiryukov]

In 46797:

Site Health: Add a test for PHP default timezone.

The test reports a failure if the default timezone was changed with date_default_timezone_set() to anything other than UTC.

WordPress historically uses UTC as the default timezone for calculating date and time offsets, overriding it is not recommended and can cause widespread and obscure issues.

Props Rarst, Clorith, TimothyBlynJacobs.
Fixes #48692.

[SergeyBiryukov]

In 46798:

Site Health: Add a test for PHP default timezone.

The test reports a failure if the default timezone was changed with date_default_timezone_set() to anything other than UTC.

WordPress historically uses UTC as the default timezone for calculating date and time offsets, overriding it is not recommended and can cause widespread and obscure issues.

Props Rarst, Clorith, TimothyBlynJacobs.
Merges [46797] to the 5.3 branch.
Fixes #48692.

[johnbillion]

@Rarst What do you think about promoting this problem to a _doing_it_wrong() rather than just a health check item?

[johnbillion]

See also #50055

[Rarst]

We can't really _doing_it_wrong() at the right moment since date_default_timezone_set() is upstream function call.

Checking that system is in an invalid state, rather than system being put into invalid state, doesn't seem like normal _doing_it_wrong() usage. Site Health seemed like a better fit.