Re: Invalid date/time handling - strtotime()
| From: | Yasuo Ohgaki | Date: | Tue, 08 Sep 2015 21:22:22 +0000 |
| Subject: | Re: Invalid date/time handling - strtotime() | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-88120@lists.php.net to get a copy of this message | ||
Hi Derick,
On Wed, Sep 9, 2015 at 1:31 AM, Derick Rethans <derick@php.net> wrote:
> Currently, it works as follows by design:
>
> - the parser, allows for each unit (year, month, day, hour, minute,
> second) the full range of values. For a year that's just 4 digits, for
> a month that's 0-12, day is 0-31 and for hour and minute it's 0-59.
>
> - 60 is allowed for seconds, as sometimes date strings with that
> leapsecond do show up. But PHP implements Unix time where "60" is not
> a valid second number and hence it overflows. There is some more
> background information at http://drck.me/leapsec-6ye
>
> - strtotime() returns false if any number is outside of the ranges, and
> new DateTime() throws an exception.
>
> - the parser is dumb, and doesn't do any checks to make it faster (and
> more generic)
>
> - *but*, there is an additional check if you pass in an invalid date
> (like your suggested $strict):
>
> $ php -r '$res = date_parse("2015-09-31");
> var_dump($res["warnings"]);'
>
> array(1) {
> [11] =>
> string(27) "The parsed date was invalid"
> }
>
> - It is already possible to handle the edge cases, but then you need to
> supply the right format. Otherwise there are too many possible
> confusing and unintuitive results coming out of the parser:
>
> php -r '$res = date_create_from_format("Y-m-d", "2015-09-34");
> var_dump($res);'
>
> class DateTime#1 (3) {
> public $date =>
> string(26) "2015-10-04 17:24:43.000000"
> public $timezone_type =>
> int(3)
> public $timezone =>
> string(13) "Europe/London"
> }
>
> - We can't add a second argument to strtotime(), because it already
> exists.
>
> - Having a "strict" option to strtotime() does also not work, as that
> would mean two distinct parsing routines.
>
> With all those concerns, as well as functionality to handle edge cases
> in place, I do not think we should change anything.
Thank you for detailed explanation.
I'm OK with current design/API. How about add documentation for more precise
date/time parsing and handling to strtotime() manual page?
One concern is "0000-00-00" date. MySQL uses it as invalid date and strtotime()
produces non intuitive result. It should be added to the document also.
I made a bug report to track this.
https://bugs.php.net/bug.php?id=70463
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net