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

go to bug id or search bugs for

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 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: 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

Pull Requests

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-2025 The PHP Group
All rights reserved. 		Last updated: Fri Oct 31 07:00:01 2025 UTC