Bug #79580 [Com]: date_create_from_format misses leap year
Edit report at https://bugs.php.net/bug.php?id=79580&edit=1
ID: 79580
Comment by: justinpor119 at gmail dot com
Reported by: mcab at acm dot org
Summary: date_create_from_format misses leap year
Status: Verified
Type: Bug
Package: Date/time related
Operating System: Linux
PHP Version: 7.2.30
Block user comment: N
Private report: N
New Comment:
You can, however, circumvent it if you create the DateTime object for the first day of the year then
add the number of days you need: https://www.upsers.mobi/
$date =
DateTime::createFromFormat("z Y","0 2016", new
DateTimeZone("UTC"))
->add(new DateInterval("P69D"))
;
var_dump($date);
It displays:
class DateTime#2 (3) {
public $date =>
string(26) "2016-03-10 14:46:37.000000"
public $timezone_type =>
int(3)
public $timezone =>
string(3) "UTC"
}
Previous Comments:
------------------------------------------------------------------------
[2020-05-10 18:37:57] rowan dot collins at gmail dot com
Now also raised as a PR against timelib: https://github.com/derickr/timelib/pull/80
------------------------------------------------------------------------
[2020-05-10 18:14:42] rowan dot collins at gmail dot com
Branch updated with an alternative implementation that makes mixing 'z' with any month or
day specifiers an error.
------------------------------------------------------------------------
[2020-05-10 17:21:29] rowan dot collins at gmail dot com
Test and tentative fix here: https://github.com/php/php-src/compare/PHP-7.3...IMSoP:bug-79580
(will actually need a change to timelib, but I'm not sure how to test it there).
This implements the approach in my last comment, but results in a change of behaviour for the
slightly odd case of specifying a day-of-year and then a month within the same time string:
echo DateTimeImmutable::createFromFormat("z m Y", '58 3
2019')->format('z: Y-m-d'), "\n";
# Previously "86: 2019-03-28"
# Now "117: 2019-04-28"
I'm not sure what to do about that, or even what the correct behaviour for that combination
should be.
------------------------------------------------------------------------
[2020-05-10 13:45:17] rowan dot collins at gmail dot com
It looks like the problem is that the 'z' specifier works by setting "month=1,
day=X" (in this case, "the 60th of January"), then normalising the date immediately.
But at that point, it doesn't know what year to use for the normalisation, so picks 1970 (which
wasn't a leap year).
https://heap.space/xref/php-src/ext/date/lib/parse_date.c?r=9c608bd1#25213
If you reverse the format, you get the expected result, because the correct year has already been
selected when the "normalise" call happens:
$TZ=timezone_open( "UTC" );
$refdate=date_create_from_format ( "Y z" ,"2020 60" ,$TZ );
echo date_format($refdate,"d/m/Y");
# 01/03/2020
A possible fix would be to delay the call to timelib_do_normalize until after the whole input has
been parsed, including the year specifier.
------------------------------------------------------------------------
[2020-05-10 13:41:20] cmb@php.net
Confirmed: <https://3v4l.org/Drfk6>.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=79580
--
Edit this bug report at https://bugs.php.net/bug.php?id=79580&edit=1
Thread (8 messages)