You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
One of the formats accepted by DateTimeZone::__construct is UTC offset, e.g., "+02:00". The method validates the argument to make sure it's valid, rejecting malformed strings like "somethingInvalid"; since PHP 8.0, this validation was improved and the method also rejects arguments like "+somtehingInvalid" that were previously accepted.
Another thing that is validated is the offset itself, provided it's not malformed. Until PHP 8.0.9, if the hours in the offset were > 99 PHP would accept the input, but return a potentially unexpected result: for instance, "+100:00" was interpreted as "+00:00"; in PHP 8.0.10 - 8.1.6 the same input would throw an exception, and in later version it's accepted again, but interpreted as "+01:00", see 3v4l. I've no idea why this was changed twice, and I'm also not here to say how it should behave.
Instead, the bug I'm reporting here (discovered by @claudiomelo) happens when you set the hours to 99, but also set the minutes to something larger than 60, which would make the offset effectively larger than 60*100 minutes.
object(DateTimeZone)#1 (2) {
["timezone_type"]=>
int(1)
["timezone"]=>
string(7) "+100:0"
}
string(7) "+100:0"
Fatal error: Uncaught ValueError: DateTimeZone::__construct(): Argument #1 ($timezone) must not contain any null bytes in /in/l7tiQ:6
I'm not quite sure what the expected output should be, given that handling of +100:02 (equivalent to +99:62) was changed a few times. Maybe it should reject the input, maybe it should treat it exactly the same as +100:02 would be treated. At any rate, it should certainly not truncate the input and add a null byte, which also makes the result unusable.
PHP Version
PHP 8.2rc3
Operating System
No response
The text was updated successfully, but these errors were encountered:
Description
One of the formats accepted by
DateTimeZone::__construct
is UTC offset, e.g., "+02:00". The method validates the argument to make sure it's valid, rejecting malformed strings like "somethingInvalid"; since PHP 8.0, this validation was improved and the method also rejects arguments like "+somtehingInvalid" that were previously accepted.Another thing that is validated is the offset itself, provided it's not malformed. Until PHP 8.0.9, if the hours in the offset were > 99 PHP would accept the input, but return a potentially unexpected result: for instance, "+100:00" was interpreted as "+00:00"; in PHP 8.0.10 - 8.1.6 the same input would throw an exception, and in later version it's accepted again, but interpreted as "+01:00", see 3v4l. I've no idea why this was changed twice, and I'm also not here to say how it should behave.
Instead, the bug I'm reporting here (discovered by @claudiomelo) happens when you set the hours to 99, but also set the minutes to something larger than 60, which would make the offset effectively larger than 60*100 minutes.
For instance, the following code:
Resulted in this output (3v4l):
I'm not quite sure what the expected output should be, given that handling of +100:02 (equivalent to +99:62) was changed a few times. Maybe it should reject the input, maybe it should treat it exactly the same as +100:02 would be treated. At any rate, it should certainly not truncate the input and add a null byte, which also makes the result unusable.
PHP Version
PHP 8.2rc3
Operating System
No response
The text was updated successfully, but these errors were encountered: