Make WordPress Core

Opened 5 years ago

Closed 5 years ago

#48660 closed defect (bug) (wontfix)

Date/Time component malfunctioning after 5.3 update.

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


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
5 years ago

Do you have any calls to date_default_timezone_set in your code? If so, please read this:

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

#2 @SergeyBiryukov
5 years ago

  • Component changed from General to Date/Time

#3 @wpnook
5 years 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
5 years 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
5 years ago

This breaks an awful lot of stuff!

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

For timezone overrides can no longer be passed.

#6 @wpnook
5 years 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 5 years ago by wpnook (previous) (diff)

#7 @wpnook
5 years 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
5 years 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:

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 5 years ago by Otto42 (previous) (diff)

#9 @Otto42
5 years 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
5 years ago

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

#11 follow-up: @ericr23
5 years 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
5 years 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
5 years 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
5 years 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.