-
Notifications
You must be signed in to change notification settings - Fork 7.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DateTime::createFromFormat: Parsing TZID string is too greedy #9700
Comments
It seems the square brackets are the problem. |
https://3v4l.org/4bcK8 clarifies; the timezone would be |
|
Ah, right, @iluuu1994! Fixing exactly this issue would be trivial: ext/date/lib/parse_date.re | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ext/date/lib/parse_date.re b/ext/date/lib/parse_date.re
index 403f98d5ea..c2cdbc483b 100644
--- a/ext/date/lib/parse_date.re
+++ b/ext/date/lib/parse_date.re
@@ -754,7 +754,7 @@ static timelib_long timelib_lookup_abbr(const char **ptr, int *dst, char **tz_ab
timelib_long value = 0;
const timelib_tz_lookup_table *tp;
- while (**ptr != '\0' && **ptr != ')' && **ptr != ' ') {
+ while (**ptr != '\0' && **ptr != ')' && **ptr != ' ' && **ptr != ']') {
++*ptr;
}
end = *ptr; Anyhow, this is a timelib issue, but I don't think we need to report upstream, since @derickr is the ext/date maintainer as well. |
It is a documentation problem DateTime::createFromFormat accepts the datetime string but is valid on the user side if the format is not repeated more than once, "p" and "e" or "e" and "e" is a repeat. Because the date to be created must be valid <?php
var_dump(DateTime::createFromFormat('Y-m-d\TH:i:sP e e', '2022-02-18T00:00:00+23:00 Europe/Berlin Europe/Rome'));
var_dump(var_dump(DateTime::GetLastErrors()));
?> Expected Result is Europe/Rome not Europe/Berlin or +23:00 (For me output date Expected is timezone: T from ISO 8601 , without Europe/Berlin or Europe/Rome ex1. 2022-02-17T23:00:00 or ex2. 2022-02-18T00:00:00+01:00) This bug: <?php
$date = DateTime::createFromFormat('Y-m-d H:i:s \[e\]', '2022-02-18 00:00:00 [Europe/Berlin]');
var_dump($date, is_object($date) ? $date->format('U') : NULL, is_object($date) ? $date->getOffset() : NULL);
var_dump(var_dump(DateTime::GetLastErrors()));
?> It would be better to create a new format, instead of validating the final part of a string with the rest of the string |
This is fixed in timelib now — I'll release and then merge this into PHP before the release of 8.0.26 and 8.1.13 |
…phpGH-9700 (greedy tzid parsing)
Now fixed, for PHP 8.1.14 and PHP 8.2.1. |
Description
Discovered this issue while importing a data-set from a third party.
The following code:
https://3v4l.org/W9SPY
Resulted in this output:
But I expected this output instead:
PHP Version
8.1.9 (discovered with 7.2.24)
Operating System
No response
The text was updated successfully, but these errors were encountered: