Edit report at https://bugs.php.net/bug.php?id=81565&edit=1
ID: 81565
User updated by: andrea dot sprega at slope dot it
Reported by: andrea dot sprega at slope dot it
Summary: BC break: date parsing fails when provided with
timezones including seconds
Status: Open
Type: Bug
Package: Date/time related
Operating System: Linux (The only I could try)
PHP Version: 8.0.12
Block user comment: N
Private report: N
New Comment:
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.
Previous Comments:
------------------------------------------------------------------------
[2021-11-12 15:46:13] 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 https://3v4l.org/CY4F7 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-02 13:29:37] alec at alec dot pl
https://www.php.net/manual/en/datetime.createfromformat.php
where the timezone format is described.
------------------------------------------------------------------------
[2021-11-02 13:28:15] ximarx at gmail dot com
According to https://www.iana.org/time-zones tzdata,
basically ~any timezone for an "old enough" date in the past is assigned to a sub-minute
offset value
E.g.:
```
America/Los_Angeles
Initially: -07:52:58 standard LMT
1883-11-18 20:00:00Z -08:00:00 standard PST
```
```
America/Los_Angeles
Initially: -07:52:58 standard LMT
1883-11-18 20:00:00Z -08:00:00 standard PST
```
```
Europe/London
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 12:37:43] heiglandreas@php.net
@alec
> According to the documentation +00:49:56 is not a correct timezone.
Do you have a link to that documentation?
------------------------------------------------------------------------
[2021-11-02 11:54:37] 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.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=81565
--
Edit this bug report at https://bugs.php.net/bug.php?id=81565&edit=1