Doc #81347 [Opn->Csd]: 2021-03-34 is correct date for DateTime::createFromFormat()
| From: | git@php.net | Date: | Sat, 04 Jun 2022 16:26:19 +0000 |
| Subject: | Doc #81347 [Opn->Csd]: 2021-03-34 is correct date for DateTime::createFromFormat() | ||
| References: | 1 | Groups: | php.doc.bugs |
| Request: | Send a blank email to doc-bugs+get-19463@lists.php.net to get a copy of this message | ||
Edit report at https://bugs.php.net/bug.php?id=81347&edit=1
ID: 81347
Updated by: git@php.net
Reported by: artyomnsk2012 at gmail dot com
Summary: 2021-03-34 is correct date for
DateTime::createFromFormat()
-Status: Open
+Status: Closed
Type: Documentation Problem
Package: Date/time related
Operating System: Ubuntu
PHP Version: 8.0.9
Block user comment: N
Private report: N
New Comment:
Automatic comment on behalf of derickr
Revision: https://github.com/php/doc-en/commit/f0c9bb04d7727a45747aa11dc39ec541180e67b1
Log: Fixed bug #81347: 2021-03-34 is correct date for DateTime::createFromFormat()
Previous Comments:
------------------------------------------------------------------------
[2021-10-07 01:13:57] must at valid dot be
This is not a bug.
On one hand, strtotime() is supposed to parse "about any English textual datetime description
into a Unix timestamp". As long as no reasonable Englishperson wants to textually describe a
datetime as '2021-03-34', it makes sense that strtotime() returns false whenever its
argument looks wrong according to the understanding of the common people. (There is a counterexample
"35. Mai" in German literature, but that was long before the Unix epoch, and good old
Erich K. actually intended it to look wrong, in order to enable crazy things to happen at this
date.)
On the other hand, the creation of a DateTime object from a format is just supposed to work whenever
it is possible, so it may well start from a "zero" date and the subsequently add 2021
years, 3 months, and 34 days. When I started to learn Java many years ago, the corresponding object
behaved in exactly the same way.
------------------------------------------------------------------------
[2021-08-10 16:05:16] artyomnsk2012 at gmail dot com
> DateTime(Immutable) will roll-over dates and there's currently no way to disable this.
However strtotime() function works OK
var_dump(strtotime('2021-03-34')) outputs false
------------------------------------------------------------------------
[2021-08-10 15:02:35] cmb@php.net
Apparently, this roll-over behavior is not documented (besides in
an example[1]); I think we should improve that.
[1] <https://www.php.net/manual/en/datetime.construct.php>
------------------------------------------------------------------------
[2021-08-10 14:54:35] php-bugs at allenjb dot me dot uk
DateTime(Immutable) will roll-over dates and there's currently no way to disable this. You can
detect when this happens using ::getLastErrors(). See https://www.php.net/manual/en/datetime.getlasterrors.php
I have a utility method that throws exceptions on errors creating a DateTimeImmutable object (the
exception message contains the first error encountered, but there's not usually more than 1 in
my experience):
public static function createImmutableFromFormat(string $format, string $time, \DateTimeZone
$timezone = null) : \DateTimeImmutable
{
$dt = \DateTimeImmutable::createFromFormat($format, $time, $timezone);
// DateTime errors/warnings can occur even if the object was successfully created (eg.
invalid date)
$errors = \DateTimeImmutable::getLastErrors();
if (count($errors['errors'] ?? []) > 0) {
/** @noinspection LoopWhichDoesNotLoopInspection */
foreach ($errors['errors'] as $pos => $msg) {
throw new \InvalidArgumentException($msg . ' @ character ' . $pos);
}
}
if (count($errors['warnings'] ?? []) > 0) {
/** @noinspection LoopWhichDoesNotLoopInspection */
foreach ($errors['warnings'] as $pos => $msg) {
throw new \InvalidArgumentException($msg . ' @ character ' . $pos);
}
}
if (! ($dt instanceof \DateTimeImmutable)) {
throw new \InvalidArgumentException("Invalid DateTime value specified");
}
return $dt;
}
------------------------------------------------------------------------
[2021-08-10 14:38:27] artyomnsk2012 at gmail dot com
Description:
------------
2021-03-34 00:00:00 is correct date for \DateTime::createFromFormat()
var_dump( \DateTime::createFromFormat('Y-m-d H:i:s', '2021-03-34 00:00:00') )
shows
```
class DateTime#1 (3) {
public $date =>
string(26) "2021-04-03 00:00:00.000000"
public $timezone_type =>
int(3)
public $timezone =>
string(3) "UTC"
}
```
Expected behaviour is false or null
Test script:
---------------
var_dump( \DateTime::createFromFormat('Y-m-d H:i:s', '2021-03-34 00:00:00') );
------------------------------------------------------------------------
--
Edit this bug report at https://bugs.php.net/bug.php?id=81347&edit=1