Since PHP 8.1.7 strtotime translates a date-time with DST/non-DST hour differently based on default timezone

[ashiful-kyos]

Description

For the timezone Europe/London on date 2018-10-28 two hour 01:00:00 exist - one DST and another non-DST. Following code shows that it gives two different timestamp based on the set default timezone. Which should not be the case as the string date-time provided to strtotime already contains the timezone.
Prior to PHP 8.1.7 strtotime was translating it into 1540688400 regardless set timezone.

<?php
date_default_timezone_set('America/Lower_Princes');
echo strtotime("2018-10-28 01:00:00 Europe/London") . PHP_EOL;

date_default_timezone_set('Europe/London');
echo strtotime("2018-10-28 01:00:00 Europe/London"). PHP_EOL;

Resulted in this output:

1540688400
1540684800

But I expected this output instead:

1540688400
1540688400

PHP Version

PHP 8.1.7

Operating System

No response

[cmb69]

Confirmed: https://3v4l.org/NEBOD. I'm not sure, though, whether the new behavior is intended, since the documentation states:

Each parameter of this function uses the default time zone unless a time zone is specified in that parameter. Be careful not to use different time zones in each parameter unless that is intended.

Since $baseTimestamp is not given, it may be interpreted using the default timezone.

[ashiful-kyos]

Confirmed: https://3v4l.org/NEBOD. I'm not sure, though, whether the new behavior is intended, since the documentation states:

Each parameter of this function uses the default time zone unless a time zone is specified in that parameter. Be careful not to use different time zones in each parameter unless that is intended.

Since $baseTimestamp is not given, it may be interpreted using the default timezone.

As per my test this issue is only with the date-time that has duplicate hour ie. hour in dst and non-dst. If $baseTimestamp has a role in this case it would result in different timestamp for other date-times, which is not the case. For example following code results in the same timestamp regardless default timezone.

<?php
date_default_timezone_set('America/Lower_Princes');
echo strtotime("2018-10-28 04:00:00 Europe/London") . PHP_EOL;

date_default_timezone_set('Europe/London');
echo strtotime("2018-10-28 04:00:00 Europe/London"). PHP_EOL;

output

1540699200
1540699200

[derickr]

I'm pretty sure this change has been introduced through derickr/timelib#121. These calculations are very magic, and changing them again will likely cause other issues.

Unless https://wiki.php.net/rfc/datetime_and_daylight_saving_time is implemented, both answers are "not wrong", although a little confusing. I do plan to tackle this issue, but not likely for PHP 8.2.

[ashiful-kyos]

I'm pretty sure this change has been introduced through derickr/timelib#121. These calculations are very magic, and changing them again will likely cause other issues.

Unless https://wiki.php.net/rfc/datetime_and_daylight_saving_time is implemented, both answers are "not wrong", although a little confusing. I do plan to tackle this issue, but not likely for PHP 8.2.

Let me give more example. Consider the following code

date_default_timezone_set('Europe/London');
echo strtotime("2018-10-28 01:00:00 Europe/London"). PHP_EOL;

echo (new DateTime('2018-10-28 01:00:00', new DateTimeZone('Europe/London')))->getTimestamp();

Before Php 8.1.7 both resulted in the same timestamp

1540688400
1540688400

However since PHP 8.1.7 they are different

1540684800
1540688400

If two methods are translating one date-time to two different timestamp, I don't think it is merely confusing, it is wrong.

[mitchdesign]

As someone who works a lot with hourly datasets, I am sympathetic to the complexity of these issues.

But, also I was very happy with the change made in 8.1.7, where a strtotime() on a string containing a duplicate hour will now return the timestamp of the first instance. This is in my opinion much better than the previous behaviour of returning the second one, because now a value can go back and forth using strtotime() and date() and not change. It makes many workflows a lot safer because we do not have to write special code for handling the case of our timestamp changing on us during manipulations.

Before:

v	$timestamp	$str = date('Y-m-d H:i', $timestamp)	strtotime($str)	.
8.1.6	1540684800	2018-10-28 01:00	1540688400	DIFFERENT
8.1.7	1540684800	2018-10-28 01:00	1540684800	SAME ✅

Now, the downside is due to the current issue, we still cannot rely on this behaviour.. Even though I agree that officially it is "not wrong" to give either value, the recently introduced behaviour is in practical use a lot better. So it is really inconvenient that there still is this unexpected variance.

And of course, because the whole point of passing timezones is that the default zone should not matter, I think it is a real bug that this difference exists, even if one accepts that the two values are both "not wrong".