php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #74839 DateTime::createFromFormat in PHP 7.0 creates wrong object
Submitted: 2017-07-01 06:02 UTC Modified: 2022-05-20 14:34 UTC
From: hksingla92 at gmail dot com Assigned:
Status: Wont fix Package: Date/time related
PHP Version: 7.0.20 OS: Windows 7
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: hksingla92 at gmail dot com
New email:
PHP Version: OS:

 

 [2017-07-01 06:02 UTC] hksingla92 at gmail dot com
Description:
------------
---
From manual page: http://www.php.net/datetime.createfromformat
---

While creating a datetime object using following function  

DateTime::createFromFormat('G:iA', '15:00PM');

produced this object

DateTime Object
(
  [date] => 2017-07-02 03:00:00.000000
  [timezone_type] => 3
  [timezone] => UTC
)

Its mixing "G/H" and "A" to produce wrong results as it adds extra hours resulting in wrong date and time. May be we should ignore "A" in case if "G/H" is used instead of "g/h"

Test script:
---------------
I think this array has all possible scenarios:

$test = [
   DateTime::createFromFormat('G:i', '3:00');
   DateTime::createFromFormat('G:i', '15:00');
   DateTime::createFromFormat('G:iA', '3:00AM');
   DateTime::createFromFormat('G:iA', '15:00AM');
   DateTime::createFromFormat('G:iA', '15:00PM');
];

print_r($test);

Expected result:
----------------
I was expecting to see object at last index with correct time like following

DateTime Object
(
  [date] => 2017-07-01 15:00:00.000000
  [timezone_type] => 3
  [timezone] => UTC
)


Actual result:
--------------
It produced following object:

DateTime Object
(
  [date] => 2017-07-02 03:00:00.000000
  [timezone_type] => 3
  [timezone] => UTC
)

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2018-03-09 12:11 UTC] cmb@php.net
-Status: Open +Status: Verified
 [2018-03-09 12:11 UTC] cmb@php.net
Confirmed: <https://3v4l.org/F9uj3>.
 [2018-03-13 01:25 UTC] mattficken@php.net
I can repro on 7.2.2 on Windows (3v4l is PHP on Linux, I assume).

The failing section of the output:
    [4] => DateTime Object
        (
            [date] => 2018-03-14 03:00:00.000000
            [timezone_type] => 3
            [timezone] => UTC
        )

Should be 15:00 not 3:00.



A corrected repro script (for syntax only):
<?php
$test = array(
	DateTime::createFromFormat('G:i', '3:00'),
	DateTime::createFromFormat('G:i', '15:00'),
	DateTime::createFromFormat('G:iA', '3:00AM'),
	DateTime::createFromFormat('G:iA', '15:00AM'),
	DateTime::createFromFormat('G:iA', '15:00PM')
);

print_r($test);
?>
 [2018-08-21 07:46 UTC] bjoern dot fischer at dezem dot de
I found a slightly different way of reproducing this problem: https://3v4l.org/P77ui

<?php
var_dump(datetime::createFromFormat('!h H a', '01 13 pm')); // should be "1970-01-01 13:00:00.000000" but the actual result is "1970-01-02 01:00:00.000000"

When changing the order of modifiers or leaving out one of them, the date gets calculated correctly.
 [2022-05-20 14:34 UTC] derick@php.net
-Status: Verified +Status: Wont fix
 [2022-05-20 14:34 UTC] derick@php.net
The parser is made dumb on purpose. If you insist on giving it weird input, then you can expect weird output ;-)

I'm not intending to fix this. If you feel very strongly about this, open a bug report at https://github.com/php/php-src/issues.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Tue Mar 19 08:01:29 2024 UTC