Date and time APIs for posts make wrong timezone assumptions

[Rarst]

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.

[jdgrimes]

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.

[Rarst]

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.

[Rarst]

#23203 was marked as a duplicate.

[Rarst]

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.

[Rarst]

Additional concern, that got recently highlighted, is that even if we could reliably recalculate all local times on zone change that would lead to breaking existing date permalinks whenever it causes local time to shift to a different day (or even different time at all, since even hours/minutes/seconds are valid permalink elements).

As of right now I think that it's not viable to resolve this in generic way and a reasonable manner, under backwards compatibility commitments.

Given that it worked like this for a long time, I guess it stays as a core implementation detail and something to be handled by site owners on their own if necessary.