WordPress.org

Make WordPress Core

Opened 9 months ago

Closed 8 months ago

Last modified 3 months ago

#48692 closed enhancement (fixed)

Add PHP time zone check to Site Health

Reported by: Rarst Owned by: SergeyBiryukov
Milestone: 5.3.1 Priority: normal
Severity: normal Version: 5.3
Component: Site Health Keywords: has-patch
Focuses: Cc:

Description

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. :)

Attachments (3)

48692.patch (2.2 KB) - added by Clorith 9 months ago.
48692-php-default-timezone-site-health.patch (2.0 KB) - added by Rarst 9 months ago.
48692-php-default-timezone-site-health1.patch (2.0 KB) - added by Rarst 9 months ago.

Download all attachments as: .zip

Change History (15)

This ticket was mentioned in Slack in #core-datetime by rarst. View the logs.


9 months ago

@Clorith
9 months ago

#2 @Clorith
9 months ago

  • Keywords has-patch added; needs-patch removed

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?

#3 @Rarst
9 months ago

  • Keywords needs-patch added; has-patch removed

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

#4 @Rarst
9 months ago

  • Keywords has-patch added; needs-patch removed

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.

#5 @TimothyBlynJacobs
9 months ago

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.

#6 @SergeyBiryukov
8 months ago

  • Owner set to SergeyBiryukov
  • Status changed from new to reviewing

#7 @SergeyBiryukov
8 months ago

  • Resolution set to fixed
  • Status changed from reviewing to closed

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.

#8 @SergeyBiryukov
8 months ago

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.

This ticket was mentioned in Slack in #core by sergey. View the logs.


6 months ago

#10 @johnbillion
3 months ago

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

#12 @Rarst
3 months ago

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.

Note: See TracTickets for help on using tickets.