php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #78578 Parsing of DateTime strings is VERY inconsistent
Submitted: 2019-09-21 09:03 UTC Modified: 2019-09-21 09:33 UTC
From: danielklein at airpost dot net Assigned:
Status: Not a bug Package: Date/time related
PHP Version: 7.3.9 OS: Windows 10
Private report: No CVE-ID: None
View Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
MUST BE VALID
Solve the problem:
26 + 40 = ?
Subscribe to this entry?

 
 [2019-09-21 09:03 UTC] danielklein at airpost dot net
Description:
------------
---
From manual page: https://php.net/datetime.formats.date
---
Parsing the DateTime string '24.6.08' gives 6 minutes and 8 seconds past the end of today (the start of tomorrow).

Parsing the DateTime string '25.6.08' gives midnight at the start of 25 June 2008.

That is so inconsistent it's impossible to work out which one, if either, is correct.

I've also asked a question on Stack Overflow about the weird behaviour of the DateTime string parser with many other examples.

https://stackoverflow.com/q/58038176/1166898

Test script:
---------------
var_dump(new DateTime('24.6.08'));
var_dump(new DateTime('25.6.08'));

Expected result:
----------------
I have no idea. I just know what it does output is very wrong. They should both be dates, or both be interpreted as times with hour 25 throwing an error (maybe hour 24 throwing an error too), or both be errors, or something else consistent with each other.

Actual result:
--------------
class DateTime#1 (3) {
  public $date =>
  string(26) "2019-09-22 00:06:08.000000"
  public $timezone_type =>
  int(3)
  public $timezone =>
  string(3) "UTC"
}
class DateTime#1 (3) {
  public $date =>
  string(26) "2008-06-25 00:00:00.000000"
  public $timezone_type =>
  int(3)
  public $timezone =>
  string(3) "UTC"
}

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2019-09-21 09:33 UTC] requinix@php.net
-Status: Open +Status: Not a bug
 [2019-09-21 09:33 UTC] requinix@php.net
Date parsing tries to figure out what date/time was intended with the string given - because the overall assumption is that it is something valid. If you feed it some weird input then you might get some weird output.

24.6.08 is a valid time because "24" is an acceptable hour, even if normally it would only be used with the time "24:00:00", and even though DateTime::getLastErrors() will complain about it. It's also a valid date because periods as separators indicate day+month+year ordering (as opposed to month+day+year) so the date would be June 24th 2008.

25.6.08 is not a valid time because of the hour, but it's still a valid date.

The potential ambiguity is mentioned in the docs, on the date formats page:
> Note:
> The "Day, month and two digit year, with dots or tabs" format (dd [.\t] mm "." yy) only works for the year values
> 61 (inclusive) to 99 (inclusive) - outside those years the time format "HH [.:] MM [.:] SS" has precedence.

Parsing English is hard. Stick with standard date formats if at all possible.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Apr 19 23:01:28 2024 UTC