php
Outdated info regarding multiple consecutive number signs
Description
The following code:
<?php
echo ((new \DateTimeImmutable("--1 year"))->format('Y'));
Resulted in this output in 8.2.25 / 8.3.13:
2025
But I expected this output instead (8.2.0 - 8.2.24, 8.3.0 - 8.3.12):
2023
This used to output 2025 in PHP < 8.2, but from my understanding, this behavior was intentionally changed.
I couldn’t find anything in the changelog about this change, and the Changelog section in the documentation hasn't been updated. I'm opening this issue to confirm if this is now the intended behavior.
The issue is caused by the latest update of timelib (https://github.com/php/php-src/commit/40d06fb645b42409ecb242a6ea4a4fd7207d7a0c). Note that the commit messages states:
Import timelib 2022.12
@derickr, that looks seriously wrong. We had been on 2024.2 already.
I would argue that the format "--1 year" is valid and IMO shouldn't be allowed. But the proper approach would be to deprecate such wrong "calculations" and change it in the next version, instead of patches.
That had already been changed a few years ago. There has been a bad update to timelib, though. Anyhow, deprecating what we had changed quite some time ago doesn't make much sense to me.
I agree. Now not much can be done, but it could be handled better in the past looking at the whole thread with change.
@derickr, that looks seriously wrong. We had been on 2024.2 already.
timelib version != timezonedb version
The timelib version is indeed the correct 2022.12, and the timezonedb version the right 2024.2 version.
The 2022.12 version has this fix in it:
"Allow for multiple signs for signed numbers again (regression)" (https://github.com/derickr/timelib/commit/8b58edb2c9827ceed3cb662209a2be3d756cac1b)
So I don't think there is anything wrong now?
timelib version != timezonedb version
Oops, mixed that up.
So https://3v4l.org/ALC7C is intentional? This should probably be documented in the manual then; while we usually don't document bug fixes, there is a note about the previous change in the migration guide, so users might be confused.
Heh - I don't know why we documented that. In any case, it should be reverted in the documentation, as we now fixed this again.