|  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: 2019-04-09 13:17 UTC
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: girgias (profile)
Status: Verified Package: Date/time related
PHP Version: Irrelevant OS:
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.
Block user comment
Status: Assign to:
Bug Type:
From: papaulsh at gmail dot com
New email:
PHP Version: OS:


 [2013-11-15 23:32 UTC] papaulsh at gmail dot com
From manual page:
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


Add a Patch

Pull Requests

Add a Pull Request


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]
-Package: date_time +Package: Date/time related
 [2018-02-13 17:33 UTC]
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]
-Type: Bug +Type: Documentation Problem
 [2018-02-14 05:45 UTC]
-Status: Open +Status: Verified
 [2018-02-14 05:45 UTC]
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.
 [2019-04-09 10:22 UTC]
-Operating System: WAMP +Operating System: -PHP Version: master-Git-2013-11-15 (Git) +PHP Version: Irrelevant -Assigned To: +Assigned To: girgias
 [2019-04-09 10:22 UTC]
Assigning to myself to remind me to add a note explaining the behavior of strtotime
 [2019-04-09 13:17 UTC]
Just FYI, we already have a detailed note and explanation on the Date Formats [1] page about this behaviour.

PHP Copyright © 2001-2021 The PHP Group
All rights reserved.
Last updated: Mon Jan 25 06:01:23 2021 UTC