Req #64814 [Com]: Nano precision is not supported while decoding RFC 3339 formatted date/times.

Edit report at https://bugs.php.net/bug.php?id=64814&edit=1 ID: 64814 Comment by: kaare at slettnes dot org Reported by: marc at weistroff dot net Summary: Nano precision is not supported while decoding RFC 3339 formatted date/times. Status: Open Type: Feature/Change Request Package: Date/time related PHP Version: 5.5.0RC1 Block user comment: N Private report: N New Comment: This bit me while fetching payment transaction data from a third party service. I'm guessing they use the iso 8609 timestamp as primary key for records as each transaction has a timestamp with nano seconds. These dates fails: - 2022-02-05T23:59:58.600200034+01:00 - 2022-02-05T23:59:58.600200000 - 2022-02-05T23:59,00000+0100 - 2022-02-05T23:59,00000 These are ok: - 2022-02-05T23:59:58.60020003+01:00 - 2022-02-05T23:59:58.60020003 - 2022-02-05T23:59,6002+01:00 (*) - 2022-02-05T23:59,6002 (*) (*) According to the iso 8609 standard, fractions are allowed in minutes as well, but are not treated correctly in php. Also, from the wikipedia article on 8601: "There is no limit on the number of decimal places for the decimal fraction. However, the number of decimal places needs to be agreed to by the communicating parties." Previous Comments: ------------------------------------------------------------------------ [2017-04-21 15:52:46] antoine dot hedgecock at gmail dot com I'm experience the same issue as the person above, go generate a timestamp with rfc3339 with a lot of precision. Php should just truncate the excess digits instead of failing with a very weird error. ------------------------------------------------------------------------ [2015-02-11 07:43:21] friedrich dot grosse at gmail dot com This is a problem for me when consuming JSON that has been generated by a service written in go. There the default format for time objects is RFC3339Nano ------------------------------------------------------------------------ [2013-05-10 17:33:46] marc at weistroff dot net I should have precise in the description of the bug that PHP returns an error when the number of digits in the "time-secfrac" part is > 8. ------------------------------------------------------------------------ [2013-05-10 17:29:15] marc at weistroff dot net Description: ------------ While trying to parse a RFC3339 datetime, PHP will generate the error "The timezone could not be found in the database". It can cause problems with other systems that produce such date/time strings. As you can see on http://3v4l.org/Bl1Kv, it affects php from version 5.2.0 to 5.5.0. Test script: --------------- <?php date_default_timezone_set('UTC'); var_dump(date_parse("2006-12-12T10:00:00.999999999-04:00")); ?> Expected result: ---------------- array(15) { ["year"]=> int(2006) ["month"]=> int(12) ["day"]=> int(12) ["hour"]=> int(10) ["minute"]=> int(0) ["second"]=> int(0) ["fraction"]=> float(0.999999999) ["warning_count"]=> int(0) ["warnings"]=> array(0) { } ["error_count"]=> int(0) ["errors"]=> array(0) { } ["is_localtime"]=> bool(true) ["zone_type"]=> int(1) ["zone"]=> int(240) ["is_dst"]=> bool(false) } Actual result: -------------- array(13) { ["year"]=> int(2006) ["month"]=> int(12) ["day"]=> int(12) ["hour"]=> int(10) ["minute"]=> int(0) ["second"]=> int(0) ["fraction"]=> float(0.99999999) ["warning_count"]=> int(0) ["warnings"]=> array(0) { } ["error_count"]=> int(1) ["errors"]=> array(1) { [0]=> string(47) "The timezone could not be found in the database" } ["is_localtime"]=> bool(true) ["zone_type"]=> int(0) } ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=64814&edit=1