WordPress.org

Make WordPress Core

Opened 3 years ago

Last modified 23 hours ago

#38774 new defect (bug)

Date and time APIs for posts make wrong timezone assumptions

Reported by: Rarst Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version: 4.6.1
Component: Date/Time Keywords:
Focuses: Cc:
PR Number:

Description

WP doesn't store timezone information in "main" (non-GMT) post fields. Many of related APIs make a wide assumption that correct time zone is merely the one set in settings right now:

<?php

d( get_the_date( DATE_W3C ) ); // 2014-11-07T13:36:31+02:00

add_filter( 'pre_option_timezone_string', function () {
        return 'America/New_York';
} );

d( get_the_date( DATE_W3C ) ); // 2014-11-07T13:36:31-05:00 < same time, different time zone

This is extremely brittle.

Timezone change in settings would make API return invalid time for all existing posts. Import from an install with different timezone setting would make all created posts display invalid time. And so on.

It would be more reliable to base API return on GMT post fields (which does by definition have timezone information) and then convert to currently set time zone setting for return.

Change History (4)

#1 follow-up: @jdgrimes
2 years ago

I think that this partly depends on what the date is going to be used for. In some cases the intention might be to show what time it actually was on the site *at the time a post was published*, not what time it was on the site then relative to the site's current timezone.

Consideration needs to be given to what circumstances cause a site's timezone to change, and which of these results users are most likely to want/expect.

However, when formatted with the timezone, as in your example, the result does of course need to be generated from the GMT fields, because the timezone of the other fields is not known.

#2 in reply to: ↑ 1 @Rarst
2 years ago

Replying to jdgrimes:

In some cases the intention might be to show what time it actually was on the site *at the time a post was published*, not what time it was on the site then relative to the site's current timezone.

While I fully consider this a valid use case, it’s not what current API either promises or attempts to deliver.

I think the first step should be fixing things to a point that they produce correct time at all, which is very long overdue for Date/Time component.

#3 @Rarst
16 months ago

#23203 was marked as a duplicate.

#4 @Rarst
23 hours ago

We've considered going canonical UTC in this Date/Time component revamp.

Unfortunately it's too nuanced to happen right now.

In a nutshell UTC favors working with time that had already happened and local time can be reliable calculated for any time zone from it.

However for future time local time is preferable since users operate with that rather than UTC and future time zone offsets are essentially unknowable (being dependent on such things like political decisions about them).

Since we are locked in to current database schema for backwards compatibility, there is no good take to advance this at the moment.

Note: See TracTickets for help on using tickets.