You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Since PHP 8.1.7 strtotime translates a date-time with DST/non-DST hour differently based on default timezone #9165
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.
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.
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.
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.
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.
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".
Activity
cmb69 commentedon Jul 27, 2022
Confirmed: https://3v4l.org/NEBOD. I'm not sure, though, whether the new behavior is intended, since the documentation states:
Since
$baseTimestampis not given, it may be interpreted using the default timezone.ashiful-kyos commentedon Jul 27, 2022
As per my test this issue is only with the date-time that has duplicate hour ie. hour in dst and non-dst. If
$baseTimestamphas 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.output
derickr commentedon Aug 10, 2022
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 commentedon Aug 11, 2022
Let me give more example. Consider the following code
Before Php 8.1.7 both resulted in the same timestamp
However since PHP 8.1.7 they are different
If two methods are translating one date-time to two different timestamp, I don't think it is merely confusing, it is wrong.
mitchdesign commentedon Aug 11, 2022
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:
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".
Skip PHP 8.1 unstable daylight savings tests
Skip PHP 8.1 unstable daylight savings tests (#146)
Fixed php#9165: strtotime translates a date-time with DST/non-DST hou…
derickr commentedon Sep 14, 2022
PR at #9538 — for PHP 8.1.11.
Integrate timelib 2022.02
tomandersen commentedon Nov 21, 2023
https://onlinephp.io?s=s7EvyCjg5dLXV3DNK0ktUqjMLy1SSM5PSVXISC1K1VFIzcvKr1Tk5UpNzshXUIrJC_AIULDQM1IoK1Yw1zNRKM8syVAoLikqyS_JzE1VSCpNt7dXiMlTsublQujRVTDNABpbDBEHi8K1aChZWhmaaOtCVChpWiO0EdSEpIeXCwA%2C&v=7.4.33%2C8.2.10
`<?php
// Enter your code here, enjoy!
echo "\nPHP 8.2 vs 7.4 with strtotime bug?? \n";
echo "\n- 5hours\n";
echo strtotime("9:14+-5hours");
echo "\n5hours\n";
echo strtotime("9:14+5hours");
`
`PHP7.4 with strtotime bug??
1700540040
5hours
1700576040`
`PHP 8.2
1700576040
5hours
1700576040`
tomandersen commentedon Nov 21, 2023
Should we all just stop calling strtotime() ?
ranvis commentedon Nov 21, 2023
@tomandersen
Looks like OT, but "+-" doesn't work on 8.2.
tomandersen commentedon Nov 22, 2023
Thanks, I should have thought about that, some new string behaviour. I swear it wasn’t my code!