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

WordPress Trac noreply at wordpress.org
Wed Jun 25 18:18:30 UTC 2014


#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:
--------------------------+-----------------------
Changes (by buley):

 * status:  closed => reopened
 * resolution:  worksforme =>


Comment:

 This issue seems unduly dismissed.

 [[Image(https://cloud.githubusercontent.com/assets/86985/3389378/46bb2ddc-
 fc94-11e3-8979-f95d84377aa5.png)]]

 [[Image(https://cloud.githubusercontent.com/assets/86985/3389354/e0d0b97e-
 fc93-11e3-9828-e9e906f95f6f.png)]]

 In the core code above and on trac
 https://core.trac.wordpress.org/browser/trunk/src/wp-
 admin/includes/revision.php#L172 WordPress is shown to use `$modified` to
 calculate the pretty date (`dateShort`) but `$modified_gmt` to show the
 `human_time_diff()` (`timeAgo`). This causes apparent time travel.

 >  I'm guessing you were experiencing some sort of server configuration
 issue

 This does not seem to be possible to me given the equivalence between the
 dates, but I'm interested in hearing how my servers might be
 misconfigured. Looking for answers here because I see no other way to
 filter these values, as they are templated on the client side.

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


More information about the wp-trac mailing list