Date/Time component malfunctioning after 5.3 update.

[hannahmussey]

After we updated a client site to WordPress 5.3, custom date/time fields are displayed incorrectly in that they automatically add 5 hours to the desired date. We have the timezone set to +8hrs (P/ST), but the client timezone these dates should be in are +5hrs (E/ST). Still, it doesn't make sense that they would add 5 hours.

Even on post editor pages, after we input a date/time field and save the post, the different date/time appears on the updated editor page.

This only began happening when we updated to 5.3.

[Otto42]

Do you have any calls to date_default_timezone_set in your code? If so, please read this: ​https://wordpress.org/support/topic/read-this-first-wordpress-5-3-master-list/#post-12124062

WordPress expects the default timezone to be UTC at all times. You cannot change this without side effects.

[wpnook]

There are some pretty serious issues here with wide-ranging consequences for any builds featuring custom date functionality.

Consider the following: a city-specific events aggregator outputing dates using PHP's date() function instead of the DateTime class. After this update, using date_default_timezone_set() no longer works.

The dates and times for all of those events will now be output in UTC time, which creates all sorts of problems. Yes, it's ideal to use the DateTime class over date(), where the timezone can be set dynamically, but legacy code is sometimes a difficult reality.

[Otto42]

The need for WordPress to set the default timezone to UTC has existed for many years. This is not new behavior in that respect. What's new is that with a lot of the PHP 4 (literally) legacy code removed, then WordPress relies on this to be the case even more now.

So, if you're setting the default timezone, you will have different issues now than you did before, but you already would have had issues before. Not setting the default timezone has already been the recommended behavior for plugins and other addons for many years.

[wpnook]

This breaks an awful lot of stuff!

It breaks date filters for anyone uses Twig or Timber as well:

​https://twig.symfony.com/doc/3.x/filters/date.html

For timezone overrides can no longer be passed.

[wpnook]

Update: This is not factual, see post directly below.

So consider the purpose of date_default_timezone_set(), used in a script in conjunction with a procedural date() call, used to output a particular date/time. The purpose is to set the timezone for the specific script, not globally -- so that the date can be output in a particular timezone, presumably a local one, in instances where the local time is the only applicable time.

This update, in effect, breaks that core PHP functionality.

Post-5.3 update, using date_default_timezone_set() has no effect on the timezone output of date().

[wpnook]

Let me offer an addendum: using procedural date() in conjunction with date_default_timezone_set() does seem to work -- ultimately the issue here is that the update breaks Twig's date filter.

[Otto42]

Again, this update doesn't really change anything. WordPress has set the default timezone to UTC for 10 years.

Here's the change when it was first introduced: https://core.trac.wordpress.org/changeset/12315

If your code changes the default timezone, then it will break some of WordPress's date handling. This has been the case for almost 10 years.

[Otto42]

Also, there is no good answer here. If we changed it to not do that and to set the default timezone according to the dropdown in WordPress (which is arguably the way it should work), then you will simply break any other code which relies on WordPress setting the timezone to UTC. You'll probably break more code that way than maintaining the status quo.

In other words, this way is the way of preserving legacy code. Other code should not be changing the default timezone, and they have been breaking things by doing so in WordPress for 10 years now.

[wpnook]

I will dig deeper into why the 5.3 update breaks Twig's date filter.

[ericr23]

Our time zone is set to "New York" (UTC-5). A post published on Dec. 1 at 20:24 local time shows the permalink correctly as …/12/01/…, but on the index page, the_permalink() incorrectly returns …/12/02/… whereas the the_time() correctly returns 12/01.

In the RSS2 feed, the pubDate is 02 Dec 2019 01:24:30 +0000 and the_permalink_rss() correctly returns …/12/01/…

Changing the publish time to 18:24 resolves the discrepancies by keeping it more than 5 hours before midnight, but that's obviously just a workaround.

[SergeyBiryukov]

Replying to ericr23:

Our time zone is set to "New York" (UTC-5). A post published on Dec. 1 at 20:24 local time shows the permalink correctly as …/12/01/…, but on the index page, the_permalink() incorrectly returns …/12/02/… whereas the the_time() correctly returns 12/01.

The permalink issue is being tracked in #48623, the fix will ship with WordPress 5.3.1.

[Rarst]

I seem to have missed this one, notifiers just don't like me for some reason.

First, I don't think @hannahmussey confirmed if the issue is related to changing time zone or not. We would need that to proceed with ticket one way or another.

As far as for date_default_timezone_set() that's the situation - it had never been supported by core and changing it routinely breaks things. We currently work on resolving the latter part - that is having it changes not break things in core, however that doesn't extend to all the third party WP code out there.

More so using it is neither necessary or common practice in general PHP development. Personally I had never seen hard need to use it, over using proper date and timezone objects.

If anyone needs pointers on changing existing code making use of it, I am always happy to hear out the use case and chat in WP slack / #core-datetime channel.

[Rarst]

5.3.1 had shipped a "PHP default timezone" check in Tools > Site Health, that simplifies diagnosing that issue.

Unless OP confirms that their issue is definitely different, this isn't directly actionable and will be handled over time in continued progress of making core insensitive to PHP time zone changes (the next step is getting rid of strtotime() in core).