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:         [email protected]
 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] [email protected]

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] [email protected]

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