WordPress.org

Make WordPress Core

#48660 closed defect (bug) (wontfix)

Date/Time component malfunctioning after 5.3 update.

Reported by: hannahmussey Owned by:
Milestone: Priority: normal
Severity: major Version: 5.3
Component: Date/Time Keywords: reporter-feedback
Focuses: Cc:

Description

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.

Change History (14)

#1 @Otto42
16 months ago

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.

#2 @SergeyBiryukov
16 months ago

  • Component changed from General to Date/Time

#3 @wpnook
16 months ago

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.

#4 @Otto42
16 months ago

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.

#5 @wpnook
16 months ago

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.

#6 @wpnook
16 months ago

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

Last edited 16 months ago by wpnook (previous) (diff)

#7 @wpnook
16 months ago

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.

#8 @Otto42
16 months ago

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.

Last edited 16 months ago by Otto42 (previous) (diff)

#9 @Otto42
16 months ago

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.

#10 @wpnook
16 months ago

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

#11 follow-up: @ericr23
15 months ago

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.

#12 in reply to: ↑ 11 @SergeyBiryukov
15 months ago

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.

#13 @Rarst
15 months ago

  • Keywords reporter-feedback added

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.

#14 @Rarst
15 months ago

  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Status changed from assigned to closed

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

Note: See TracTickets for help on using tickets.