[wp-trac] [WordPress Trac] #25365: timeAgo attribute for revisions produces the wrong result due to missing UTC in strtotime

[WordPress Trac]

#25365: timeAgo attribute for revisions produces the wrong result due to missing
UTC in strtotime
--------------------------+-----------------------
 Reporter:  biranit       |       Owner:
     Type:  defect (bug)  |      Status:  reopened
 Priority:  normal        |   Milestone:
Component:  Revisions     |     Version:  3.6.1
 Severity:  normal        |  Resolution:
 Keywords:                |     Focuses:
--------------------------+-----------------------

Comment (by adamsilverstein):

 Thanks for the feedback -

 When using WordPress the timezone should **not** be set in PHP.  WordPress
 //explicitly sets the timezone to UTC in wp-settings.php// and
 **calculates all offsets from there** - see
 [https://core.trac.wordpress.org/browser/tags/3.9.1/src/wp-
 settings.php#L42 here] -- setting the timezone elsewhere in PHP is
 confusing WordPress internally.

 I tried changing the code from using modified_gmt to modified as suggested
 above and that does fix the revisions page **if I set the timezone in
 PHP** - otherwise the times are all off. Since setting the timezone in PHP
 is against recommended practice, making this change would likely have a
 negative affect for everyone who doesn't have this set.

 Where and why are you setting the timezone in your PHP with
 date_default_timezone_set? can you try removing that set statement to see
 if the issue is resolved?  Setting the timezone in WordPress should be
 sufficient.

 If you absolutely have to set the timezone for a block of PHP, try setting
 it back to UTC at the end of the block, so WordPress internal calculations
 are not affected.

 Hope that helps.

 Replying to [comment:11 buley]:
 > I can confirm that in my case timezone is set correctly in WordPress
 under Settings->General. It's also set correctly in PHP using
 `date_default_timezone_set()`.
 >
 > To repeat, the problem is not that WordPress uses UTC to represent dates
 internally. The problem is that in one single instance feeds
 `human_time_diff()` a UTC date for external display of a localized time.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/25365#comment:12>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform