Bug #81565 [Com]: BC break: date parsing fails when provided with timezones including seconds

Edit report at https://bugs.php.net/bug.php?id=81565&edit=1 ID: 81565 Comment by: antonino dot spampinato86 at gmail dot com 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: $date = \DateTime::createFromFormat( '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 Previous Comments: ------------------------------------------------------------------------ [2021-11-12 16:15:41] 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 15:54:44] 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 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 ``` ------------------------------------------------------------------------ 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