Opened 5 years ago
Closed 5 years ago
#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)
#3
@
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
@
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
@
5 years 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
@
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()
.
#7
@
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
@
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: 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.
#9
@
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.
#11
follow-up:
↓ 12
@
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
@
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
@
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
@
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).
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-12124062WordPress expects the default timezone to be UTC at all times. You cannot change this without side effects.