Bug #76770 [Asn->Csd]: 'U' modifier in 'datetime::createFromFormat' adds seconds to other specifiers

Edit report at https://bugs.php.net/bug.php?id=76770&edit=1 ID: 76770 Updated by: cmb@php.net Reported by: bjoern dot fischer at dezem dot de Summary: 'U' modifier in 'datetime::createFromFormat' adds seconds to other specifiers -Status: Assigned +Status: Closed Type: Bug Package: Date/time related Operating System: Linux PHP Version: Irrelevant Assigned To: derick Block user comment: N Private report: N New Comment: This issue is fixed with the latest timelib, and as such as of PHP 8.0.0. Previous Comments: ------------------------------------------------------------------------ [2019-02-22 23:05:37] petk@php.net The following pull request has been associated: Patch Name: Fix #76770: Unix time parsed as non relative. On GitHub: https://github.com/php/php-src/pull/3514 Patch: https://github.com/php/php-src/pull/3514.patch ------------------------------------------------------------------------ [2018-08-21 10:37:13] requinix@php.net Okay, so after playing with it some more, it looks like 'U' is actually magical like I suggested it should not be. https://3v4l.org/CCPrd With 'U', additional date parts are *added* to the timestamp. With other specifiers, date parts are *merged* with latter values overriding earlier values. So I'm thinking either a) 'U' should be fixed to not do that and to act like everything else, possibly with the last errors set, or b) createFromFormat should reject the string entirely, and not just with 'U' but with other inconsistent strings If it can't be changed then at least it needs to be documented. ------------------------------------------------------------------------ [2018-08-21 10:13:28] bjoern dot fischer at dezem dot de Ah. Now I get your concern. I think this is a separate problem. In my opinion, your example should just result in an error as the provided date/time-string is inconsistent. (I'm actually currently implementing a wrapper around 'datetime' that does this.) However preferring the first or the last of those two redundant specifiers would both be understandable to me. I don't really understand yet why the former should be preferred. In the issue I describe, something different happens. There we have a redundant time format where the specified date/time-string is actually consistent. But instead of just having the components accepted as consistent, they are added together. I think the use case that you describe should not be the point of 'datetime::createFromFormat()'. We have 'datetime::modify()' for that. Also this would be inconsistent with the rest of the behaviour of 'datetime::createFromFormat()'. For example: 'var_dump(datetime::createFromFormat('!d j', '02 2')->getTimestamp());' currently results in the time-stamp '86400'. By the reasoning you propose it should result in the time-stamp '172800'. ------------------------------------------------------------------------ [2018-08-21 08:50:57] requinix@php.net I know, but I still want to know your opinion. Because I would argue that using 'U' or using a full 'Y-m-d H:i:s' should both work the same way when it comes to something that "fully specifies the time". DateTime::createFromFormat("!Y-m-d H:i:s D", "2018-08-20 12:34:56 Tuesday") becomes either 8-20 (Monday) or 8-21 (Tuesday), depending. If it's the former then we've established a consistent behavior and I can understand it. If it's the latter then I think that's inconsistent and it implies 'U' is something unique and magical. Either way I don't think we can change this behavior, if only for the simple reason that changing 'U' (at least) to work like this would break any existing code that wants to do something like DateTime::createFromFormat("!U D", "{$timestamp} Tuesday") which would, hypothetically, be there to start with one timestamp and then deliberately modify it - much like how strtotime() is often used. ------------------------------------------------------------------------ [2018-08-21 07:15:09] bjoern dot fischer at dezem dot de Hello requinix. I don't seem to understand your question. The code you posted has no 'U' modifier in it and the reported bug only appears when using that modifier. ------------------------------------------------------------------------ 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=76770 -- Edit this bug report at https://bugs.php.net/bug.php?id=76770&edit=1