Creating a post might fail during fall's DST switch due to ambiguous time

[danielbachhuber]

When I use wp_insert_post() to create a post when timezone_tz is Europe/London ​ref, the post gets scheduled for the future.

$post_date is established here: https://core.trac.wordpress.org/browser/tags/4.3/src/wp-includes/post.php#L3272

Because $post_date_gmt isn't supplied, it's set here: https://core.trac.wordpress.org/browser/tags/4.3/src/wp-includes/post.php#L3292

However, get_gmt_from_date() returns the same value as its supplied, when it should return an hour less (as Europe/London respects DST). gmdate() returns the proper GMT date (one hour less) so the post gets forced to future ref

Here's debug of get_gmt_from_date():

<?php
$format = 'Y-m-d H:i:s';
$string = '2015-10-25 01:23:08';
$tz = 'Europe/London';
$datetime = date_create( $string, new DateTimeZone( $tz ) );
echo $datetime->format( $format ) . PHP_EOL;
// 2015-10-25 01:23:08
$datetime->setTimezone( new DateTimeZone( 'UTC' ) );
echo $datetime->format( $format ) . PHP_EOL;
// 2015-10-25 01:23:08, but should be 2015-10-25 00:23:08

Is this a bug in PHP, or how we're using DateTime? Tested on PHP 5.6.14, 5.5.9, and 5.5.27

[danielbachhuber]

Oh. London apparently falls back on the last Sunday of October (e.g. today in Europe/London).

I have no idea what this bug actually is, but apparently get_gmt_from_date() produces a different value than gmdate() in a maybe twice per year edge case.

[danielbachhuber]

After talking this through time and time again, @viper007bond and I feel reasonably confident that DST should be abolished.

The bug is most likely that 1:23 am occurs twice in London on 2015-10-25. DateTime doesn't know how to distinguish between them when doing relative time conversions so it assumes the later one. It could pick the correct one if it knew the UTC time.

[Viper007Bond]

This bug should be avoidable if we stop determining GMT (UTC) date/time based on local date/time when creating a post without a provided date/time. Since those values will default to now, we don't need to convert timezones because we know what now is in UTC. We can determine now in UTC and local time independently of each other.

[Viper007Bond]

Replying to Viper007Bond:

This bug should be avoidable if we stop determining GMT (UTC) date/time based on local date/time when creating a post without a provided date/time. Since those values will default to now, we don't need to convert timezones because we know what now is in UTC. We can determine now in UTC and local time independently of each other.

Note that this doesn't fix get_gmt_from_date() (I'm not sure that's possible), but it does fix trying to publish a post now and having it end up being scheduled an hour in the future.

[danielbachhuber]

Doing a search of the codebase, there are a few key places get_gmt_from_date() is used:

• _wp_translate_postdata() ref
• wp_insert_post() ref
• wp_insert_comment() ref
• Throughout wp_xmlrpc_server

I have two practical recommendations:

• In the wp_insert_*() functions, when neither *_date nor *_date_gmt values are passed, *_date should be set from *_date_gmt
• Include a concise note in get_gmt_from_date()'s PHPdoc mentioning this scenario where the function return value is ambiguous.

[Rarst]

Replying to danielbachhuber:

After talking this through time and time again, @viper007bond and I feel reasonably confident that DST should be abolished.

The bug is most likely that 1:23 am occurs twice in London on 2015-10-25. DateTime doesn't know how to distinguish between them when doing relative time conversions so it assumes the later one. It could pick the correct one if it knew the UTC time.

To be more precise what happens isn't just random assumption. PHP has a registered transition for Europe/London from BST to GMT at 2015-10-25T01:00:00+0000. So I think input before 01:00 is considered still in BST and after 01:00 is considered in GMT.

And yeah, on WP side it should ideally all just operate in UTC as much as possible. Concept of a "local" time for a post is deeply broken in many places.

[Rarst]

I did some work on conversion functions in #31809, but inherently it cannot address this problem. If you provide an ambiguous input you are going to get uncertain result.

I am refining a title of the issue a bit and will see if I can work through insertion logic and if there are any clear ways to address it in there.

But I suspect since WP is committed to store and operate with ambiguous local date/time data, we are kind of stuck with edge cases like these. You just cannot reliably inflate lacking data to a more meaningful state.