Doc #62476 [Opn]: DateTime::createFromFormat z format incorrect wrt 29.02

Edit report at https://bugs.php.net/bug.php?id=62476&edit=1 ID: 62476 Updated by: cmb@php.net Reported by: kaido at tradenet dot ee Summary: DateTime::createFromFormat z format incorrect wrt 29.02 Status: Open Type: Documentation Problem Package: Date/time related Operating System: debian 2.6.32-5-amd64 PHP Version: 5.4.4 Block user comment: N Private report: N New Comment: Ah, just found that the change in PHP 8.0.10 is due to fixing bug #79580. Apparently, when the day-of-year is parsed before the given year, the day-of-year is applied to the current year. Previous Comments: ------------------------------------------------------------------------ [2021-10-01 12:38:47] cmb@php.net As of PHP 8.0.10, it is no longer possible to use "z.Y" at all ("A 'day of year' can only come after a year has been found"). Fixing the unsupported format to "Y.z" brings the desired results[1]. So this is a documentation problem. [1] <https://3v4l.org/2In8R> ------------------------------------------------------------------------ [2016-06-14 12:18:19] cmb@php.net Related To: Bug #70956 ------------------------------------------------------------------------ [2015-03-10 09:14:44] info at giorgiosironi dot com Possible workaround: $ php -r 'echo DateTime::createFromFormat("z Y", "59 2016")->format("Y-m-d"), PHP_EOL;' 2016-03-01 $ php -r 'echo DateTime::createFromFormat("Y z", "2016 59")->format("Y-m-d"), PHP_EOL;' 2016-02-29 $ php -v PHP 5.4.31-1+deb.sury.org~precise+1 (cli) (built: Jul 25 2014 07:04:32) Copyright (c) 1997-2014 The PHP Group Zend Engine v2.4.0, Copyright (c) 1998-2014 Zend Technologies with Zend OPcache v7.0.2, Copyright (c) 1999-2013, by Zend Technologies If it can be any helpful in Google searches for this bug, we encountered this when using MongoDB $dayOfYear aggregation option. ------------------------------------------------------------------------ [2015-02-03 19:40:05] kohenkatz at gmail dot com Why is this still an issue 2.5 years later? I see it in 5.5.12 on Ubuntu 14.10 and 5.6.5 on Windows Server 2012. ------------------------------------------------------------------------ [2012-07-05 19:13:35] kaido at tradenet dot ee the bug was introduced in commit 4c9fad8b362a7d2b6a94b4961e4b2dc037b2766d to fix the bug #51994. the problem is that in parse_date.c in timelib_parse_from_format() function, in case of the z-format option, the date is immidiately normalized, but at that point (if year format option happens to come _after_ the z - ie right from it) year is not yet set, and -99999 is used instead, which most probably is not a leap year :) the obvious quick solution is to call timelib_do_normalize() only if year is set already. doing so passes all test, too. even the one for #51994. should the timelib_do_normalize() call be added to year option, too, if date/month are set at that point? also, in timelib_do_normalize() there seems to be 3 checks like: if (time->s != TIMELIB_UNSET) .. shouldn't 2nd and 3rd be "if (time->i != TIMELIB_UNSET)" and "if (time->h != TIMELIB_UNSET)" instead ? (I did not dig deep enough, to be sure, though) ------------------------------------------------------------------------ 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=62476 -- Edit this bug report at https://bugs.php.net/bug.php?id=62476&edit=1