[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