php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Doc Bug #66104 strtotime reports "2011-02-31" and "2011-11-31" as valid dates
Submitted: 2013-11-15 23:32 UTC Modified: 2018-02-14 05:45 UTC
Votes:2
Avg. Score:4.5 ± 0.5
Reproduced:2 of 2 (100.0%)
Same Version:1 (50.0%)
Same OS:1 (50.0%)
From: papaulsh at gmail dot com Assigned:
Status: Verified Package: Date/time related
PHP Version: master-Git-2013-11-15 (Git) OS: WAMP
Private report: No CVE-ID: None
Have you experienced this issue?
Rate the importance of this bug to you:

 [2013-11-15 23:32 UTC] papaulsh at gmail dot com
Description:
------------
---
From manual page: http://www.php.net/function.strtotime#refsect1-function.strtotime-description
---
My summary info should be sufficient to define the problem, if further clarification is needed please contact me.


Test script:
---------------
if  (!strtotime("2011-02-31")) {
     echo "<br />Invalid date";
}

Expected result:
----------------
Invalid date


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2015-09-30 14:54 UTC] boliveirasilva at gmail dot com
The same problem occurs for the following dates. (year doesn't matter)

'02/31/2014', '2016/02/31',
'02/30/2015', '2014/02/30',
'02/29/2015', '2015/02/29',

'31-02-2015', '2015-02-31', 
'30-02-2015', '2015-02-30',
'29-02-2015', '2015-02-29',

'11/31/2014', '2016/11/31', 
'31-11-2015', '2015-11-31'
 [2017-04-01 19:47 UTC] tpunt@php.net
-Package: date_time +Package: Date/time related
 [2018-02-13 17:33 UTC] cmb@php.net
This looks more like a documentation problem.  Actually,
strtotime() is very liberal in what it takes.  `2011-02-31` is
simply treated as `2011-03-03`.  Use checkdate() to check whether
a given date is valid.
 [2018-02-13 17:34 UTC] cmb@php.net
-Type: Bug +Type: Documentation Problem
 [2018-02-14 05:45 UTC] requinix@php.net
-Status: Open +Status: Verified
 [2018-02-14 05:45 UTC] requinix@php.net
I am rather tired of explaining this every other month. How about a note (warning?) that says something along the lines of how strtotime does not validate the input but instead tries to interpret it as a date in the most reasonable way possible. Month overflow is the most common issue by far; 2011-02-31 is not a valid date but the "most reasonable" interpretation of it is 3 days after 2011-02-28 which would be 2011-03-03. And other GNU/OSS date parsers act similarly. The other common issue is passing a timestamp and expecting to get that same value back (should have been "@timestamp") but strtotime reads it as some compound format without delimiters, like HHMMSSYYYY.
 
PHP Copyright © 2001-2018 The PHP Group
All rights reserved.
Last updated: Mon Dec 17 02:01:26 2018 UTC