Req #70701 [Opn->Csd]: Add support for seconds in timezone offset

Edit report at https://bugs.php.net/bug.php?id=70701&edit=1 ID: 70701 Updated by: derick@php.net Reported by: p at wspnr dot com Summary: Add support for seconds in timezone offset -Status: Open +Status: Closed Type: Feature/Change Request Package: Date/time related Operating System: All PHP Version: 7.0.0RC4 -Assigned To: +Assigned To: derick Block user comment: N Private report: N New Comment: The fix for this bug has been committed. If you are still experiencing this bug, try to check out latest source from https://github.com/php/php-src and re-test. Thank you for the report, and for helping us make PHP better. This is now supported in Git master, for PHP 8.2, as bug #81565. https://3v4l.org/Q8XHr/rfc#output Previous Comments: ------------------------------------------------------------------------ [2021-11-12 18:08:22] antonino dot spampinato86 at gmail dot com Related To: Bug #81565 ------------------------------------------------------------------------ [2017-03-19 11:57:18] heiglandreas@php.net As the Olson-DB also contains the second-offset (https://github.com/eggert/tz/blob/c040ac6cb98d8c564a67e37468512d3e0447080b/europe#L1282) we should perhaps rethink about that, even though ISO only talks about HH:MM-Offset. But they don't specifically disallow the usage of seconds for offset… ------------------------------------------------------------------------ [2016-09-26 11:52:56] jan dot drabek at trigama dot eu We encountered this bug when we developed application for timezone Europe/Luxembourg and used historic dates (1900-01-01 00:00:00) and we have found that at that times they used timezone with +00:24:36. (There is also another such timezone Paris Mean Time, see https://www.timeanddate.com/time/time-zones-history.html). Also as p@wspnr.com thinks this is clearly a problem of interoperability, especially with PostgreSQL. ------------------------------------------------------------------------ [2015-10-13 09:57:02] derick@php.net PHP internally does support these second offset timezones. And Toronto is by no means the only locality with this "issue". For example: <?php date_default_timezone_set("Europe/Amsterdam"); $dt1 = new DateTimeImmutable("Wed Jun 30 23:59:59 1937"); echo $dt1->format(DateTime::ISO8601 . ' \i\n \s\e\c: Z'), "\n"; $dt2 = $dt1->modify("+1 second"); echo $dt2->format(DateTime::ISO8601 . ' \i\n \s\e\c: Z'), "\n"; ?> Produces: 1937-06-30T23:59:59+0119 in sec: 4772 1937-07-01T00:00:28+0120 in sec: 4800 However, the ISO 8601 standard that we use for parsing and formatting timezone offsets only allows "+hh:mm, +hhmm, or +hh" [1] and hence PHP doesn't understand parsing "2015-09-15 01:15-05:30:30". Unfortunately, the whole parser only caters for minute resolution here, and overhauling this is not going to be an easy feat. [1] http://www.cl.cam.ac.uk/~mgk25/iso-time.html ------------------------------------------------------------------------ [2015-10-12 23:04:14] p at wspnr dot com I had the same thought when it came up in testing, as it is not documented in the PostgreSQL docs. It seems to be some sort of fallback for ranges where PostgreSQL can't find the timezone data. SELECT make_timestamptz(1895, 9, 15, 5, 30, 0.00, '-05:30:00'); => "1895-09-15 06:00:00-05" SELECT make_timestamptz(1894, 9, 15, 5, 30, 0.00, '-05:30:00'); => "1894-09-15 05:42:28-05:17:32" The problem arose because our testers entered '1111-11-11 11:11:11' as the date and time. PostgreSQL does this: SELECT make_timestamptz(1111, 1, 11, 11, 11, 11.00, 'UTC'); => "1111-11-11 05:53:39-05:17:32" Tracing this further, it seems that PostgreSQL falls back to the system timezone if it can't make sense of the input. By default, the system timezone is 'localtime', which is equivalent to the entry in the zoneinfo database. The zoneinfo database does express offsets with second precision: Zone America/Toronto -5:17:32 - LMT 1895 ------------------------------------------------------------------------ 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=70701 -- Edit this bug report at https://bugs.php.net/bug.php?id=70701&edit=1