date() <-> strtotime() conversion bug during DST switch.

[atreshilov]

Description

This happens in my application one hour per year. During DST switch only. I noticed this bug in PHP7 years ago under CentOS, but no fix for years, so I reported it.

$ date
Sun Nov 3 01:57:02 CST 2024

The following code:

<?php

date_default_timezone_set('America/Chicago');

$ts=time();
var_dump($ts);
$sql_format=date("Y-m-d H:i:s", $ts);
var_dump($sql_format);

$ts_back=strtotime($sql_format);
var_dump($ts_back);
$sql_format_back=date("Y-m-d H:i:s", $ts_back);
var_dump($sql_format_back);

Resulted in this output:

int(1730620622)
string(19) "2024-11-03 01:57:02"
int(1730617022)                                           <-- DIFFERENCE
string(19) "2024-11-03 01:57:02"

But I expected this output instead:

int(1730620622)
string(19) "2024-11-03 01:57:02"
int(1730620622)
string(19) "2024-11-03 01:57:02"

The difference between (int) values is 3600 seconds in the actual result.

Once the hour is switched to 2AM everything works as it should:

$ date
Sun Nov 3 02:00:19 CST 2024
$ php dt_test.php
int(1730620819)
string(19) "2024-11-03 02:00:19"
int(1730620819)
string(19) "2024-11-03 02:00:19"

PHP Version

PHP 8.1.28

Operating System

Oracle Linux Server release 8.9

[heiglandreas]

This is expected behavior.

When you pass a timestring not containing an offset that can occur twice during DST transition, the later occurrence will be assumed.

Without an offset there is no other way to handle this than to make a guess. Which - being a guess - will not always be correct.

The only way around this is to not store the date of log-like information in local time but in UTC and therefore not convert to a timezone with DST transitions. (note the "log-like information" here!)

[atreshilov]

This is expected behavior.

When you pass a timestring not containing an offset that can occur twice during DST transition, the later occurrence will be assumed.

Without an offset there is no other way to handle this than to make a guess. Which - being a guess - will not always be correct.

The only way around this is to not store the date of log-like information in local time but in UTC and therefore not convert to a timezone with DST transitions. (note the "log-like information" here!)

But I have TZ defined at the beginning:

date_default_timezone_set('America/Chicago');

[heiglandreas]

Yes.

Which causes the "problem".

YOu are passing 2024-11-03 01:57:02 into the strtotime function. Which not tries to create an epoch-timestamp based on the string and - as you didn't provide an offset or a timezone in the string - on the default timezone you set.

This means that it figures that there are actually 2 points in time that are referenced by that date-string and that timezone.

2024-11-03 01:57:02-05:00

and then, after 02:00:00-05:00 when the clock jumped "back" to 2024-11-03 01:00:00-06:00

2024-11-03 01:57:02-06:00

As you didn't provide the Offset and the timezone can't say which of those two you meant, strtotime has to guess which one is the one you meant and to do so it uses the later one. Which results in the 3600 second difference you are encountering.

PHPs DateTime handling in this one double hour during DST-back transitioning is - unless you are very explicit - always using the second hour.

This is know but changing it will break backwards compatibility, so it is not going to happen soon.

Especially as log-like information should always be using UTC anyhow and for event-like information that is stored in the local time this doesn't usually become a problem as it is so deep in the night that it is usually not used.

[MorganLOCode]

Indeed, if you make the offset visible to the parser (though I don't recommend using the informal abbreviation, which I'm just using to make the dump more readable; if you're going to use an offset it would be better to be explicit, and in that case it might as well be zero - i.e. UTC):

date_default_timezone_set('America/Chicago');

$ts=1730620622;
var_dump($ts);
$sql_format=date("Y-m-d H:i:s T", $ts);
var_dump($sql_format);

$ts_back=strtotime($sql_format);
var_dump($ts_back);
$sql_format_back=date("Y-m-d H:i:s T", $ts_back);
var_dump($sql_format_back);

$ts_back = $ts - 3600;
var_dump($ts_back);
$sql_format_back=date("Y-m-d H:i:s T", $ts_back);
var_dump($sql_format_back);

the numeric timestamp remains unscathed. What's more, setting $ts_back back one hour by hand shows how the offset changes.

[atreshilov]

Finally I got it. Thanks!