php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Request #64814 Nano precision is not supported while decoding RFC 3339 formatted date/times.
Submitted: 2013-05-10 17:29 UTC Modified: 2022-05-13 13:54 UTC
Votes:9
Avg. Score:4.2 ± 0.8
Reproduced:9 of 9 (100.0%)
Same Version:1 (11.1%)
Same OS:2 (22.2%)
From: marc at weistroff dot net Assigned: derick (profile)
Status: Closed Package: Date/time related
PHP Version: 5.5.0RC1 OS:
Private report: No CVE-ID: None
View Developer Edit
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: marc at weistroff dot net
New email:
PHP Version: OS:

 

 [2013-05-10 17:29 UTC] 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)
}

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2013-05-10 17:33 UTC] 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.
 [2015-02-11 07:43 UTC] 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
 [2017-04-21 15:52 UTC] 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.
 [2017-10-24 06:16 UTC] stas@php.net
-Type: Bug +Type: Feature/Change Request
 [2022-03-04 14:17 UTC] kaare at slettnes dot org 
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."
 [2022-05-13 13:54 UTC] derick@php.net
-Status: Open +Status: Closed -Assigned To: +Assigned To: derick
 [2022-05-13 13:54 UTC] derick@php.net 
Thank you for your bug report. This issue has already been fixed
in the latest released version of PHP, which you can download at
http://www.php.net/downloads.php

PHP 8.1 already trims the extra digits without throwing a warning:

$ php -r 'print_r(date_parse("2006-12-12T10:00:00.999999999-04:00"));';
Array
(
    [year] => 2006
    [month] => 12
    [day] => 12
    [hour] => 10
    [minute] => 0
    [second] => 0
    [fraction] => 0.999999
    [warning_count] => 0
    [warnings] => Array
        (
        )

    [error_count] => 0
    [errors] => Array
        (
        )

    [is_localtime] => 1
    [zone_type] => 1
    [zone] => -14400
    [is_dst] => 
)
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Thu Dec 26 12:01:30 2024 UTC