|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #81565 BC break: date parsing fails when provided with timezones including seconds
Submitted: 2021-10-29 14:08 UTC Modified: 2022-05-13 15:37 UTC
Avg. Score:3.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:1 (100.0%)
From: andrea dot sprega at slope dot it Assigned:
Status: Closed Package: Date/time related
PHP Version: 8.0.12 OS: Linux (The only I could try)
Private report: No CVE-ID: None
 [2021-10-29 14:08 UTC] andrea dot sprega at slope dot it
Past dates in some timezones used to have "weird" timezones that included seconds. Example for Europe/Rome:

Starting from PHP 8.0.10, parsing for dates with timezones including seconds started to fail -- DateTime::createFromFormat started returning false instead of a DateTime, even if it previously ignored the fractional timezone (which is fine, assuming seconds are not supported by PHP timezones).

This is a BC break for all applications that work with this kind of dates.

We believe this could be a side effect of one of these issues:

NOTE: we found out about this because of an incorrect, non validated input of a user that wrote "21" instead of "2021" as year, thus producing this weird date that ended up in our database. Then, when reading back that date on a connection with timezone set to Europe/Rome, the database performs the conversion and correctly adds the fractional timezone valid for year 21 AD.

We currently worked around the issue by manually removing seconds from the timezone (which basically restored the behavior up to 8.0.9).

Test script:

        'Y-m-d H:i:sO',
        '0021-08-21 00:00:00+00:49:56'

// NOTE: any date before 1893-10-31 23:00:00Z (with fractional timezone, as you can see from the link in the description) would reproduce the issue

Expected result:
   'date' => '0021-08-21 00:00:56.000000',
   'timezone_type' => 1,
   'timezone' => '+00:00',

Actual result:


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2021-10-29 15:13 UTC]
For reference: <>.
 [2021-11-02 11:54 UTC] alec at alec dot pl
According to the documentation +00:49:56 is not a correct timezone. So, the behavior sounds right no me.

DateTime::getLastErrors() in this case contains "The timezone could not be found in the database" error.
 [2021-11-02 12:37 UTC]

> According to the documentation +00:49:56 is not a correct timezone.

Do you have a link to that documentation?
 [2021-11-02 13:28 UTC] ximarx at gmail dot com
According to tzdata, basically ~any timezone for an "old enough" date in the past is assigned to a sub-minute offset value


Initially:           -07:52:58 standard LMT
1883-11-18 20:00:00Z -08:00:00 standard PST

Initially:           -07:52:58 standard LMT
1883-11-18 20:00:00Z -08:00:00 standard PST

Initially:           -00:01:15 standard LMT
1847-12-01 00:01:15Z +00:00:00 standard GMT

As reference: GNU date (coreutils) using tzdata 2021e

$ dpkg -s tzdata | grep -i version
Version: 2021e-0ubuntu0.20.04

$ TZ="Europe/Rome" date -d"Sat, 28 Jul 1838 17:12:33 +0000" +"%F %T %:::z"
1838-07-28 18:02:29 +00:49:56

$ TZ="Europe/London" date -d"Sat, 28 Jul 1838 17:12:33 +0000" +"%F %T %:::z"
1838-07-28 17:11:18 -00:01:15
 [2021-11-02 13:29 UTC] alec at alec dot pl where the timezone format is described.
 [2021-11-12 15:46 UTC] antonino dot spampinato86 at gmail dot com
1) Format "O" Difference from Greenwich Mean Time (GMT) without the colon between hours and minutes.
2) Problems with the transition period (2)a also this bug #80963 getTransitions does not restore the correct values ​​except the date). 2)b example timezone America/Toronto progress of +00:15:32 in php after 7.3.1 related to bug #81562
3) You must first solve problem number two and create a new format that accepts hours, minutes, seconds with or without a semicolon otherwise the behavior of php 8.0.10 is correct (read DateTime::format for "O"). The ticket is a feature request, this is my thought since if it does not exist you cannot merge, if php creates code without modifying the format historical. @derick behavior we go to the correct.

For Europe/Rome read RMT timezone (49*60) + 56.
 [2021-11-12 15:54 UTC] andrea dot sprega at slope dot it
But if the same code used to work (even though by approximating to a timezone without seconds) up to PHP 8.0.9, and it stopped in 8.0.10, how can this not be considered a BC break?

The feature request would be to handle timezones with seconds, but TBH I don't think this is of any interest to most users (at least not for me).

What it is reasonable to expect, in my opinion, is that PHP handles gracefully this kind of timezones, given that they are technically and syntactically correct.
 [2021-11-12 16:15 UTC] antonino dot spampinato86 at gmail dot com
If it is a closed project, the programmer chooses.
I agree that if the "O" format can be expanded as input +004956 while output with hours and minutes without semicolons.
the behavior prior to 8.0.10 is not correct, as I could not find it in the php documents you have to decide how to expand the date "O" and this choice is made by the php team. Otherwise, without any reference, can a user tell why the input is different from the output?
I'm normal user :)
 [2021-11-12 18:08 UTC] antonino dot spampinato86 at gmail dot com
$date =
        'Y-m-d H:i:sO',
        '0021-08-21 00:00:00+00:49:56'
var_dump($date); //timezone UTC or +00:00?. Error Real timezone is +2996

From php 8.0.10 DateTimeZone relative to fix bug #81097 (maybe this BC).

DateTime takes no seconds but uses the type +hh:mm for the time zone bug #70701
 [2022-05-13 15:37 UTC]
-Status: Open +Status: Wont fix
 [2022-05-13 15:37 UTC]
I sort of see how this can be a BC break, but @cmb's example shows that it actually never worked:

Instead of truncating the seconds in the timezone to 00:49, it cut it to 00:00.

Although timelib does internally support sub-minute timezone offsets, PHP's data structures do not. It did however not support parsing this information, which I have now added:

I don't really believe that silently truncating data on the PHP side is a good thing either. I am going to close this issue, and if you have a better solution, please open a new one at
 [2022-05-20 12:25 UTC]
Automatic comment on behalf of derickr
Log: Fixed bug #81565 (date parsing fails when provided with timezones including seconds)
 [2022-05-20 12:25 UTC]
-Status: Wont fix +Status: Closed
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sun Mar 03 02:01:30 2024 UTC