-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
ext-intl's use of IntlDateFormatter prototype has several bugs #3568
Comments
Well, if your string does not contain a timezone offset, which conversion should be applied ? There is no info about the existing timezone. |
Wow that's a fast reply!
There is, actually. We set ini_set('date.timezone', 'UTC');
|
Looking at $timezone = $timezone ?: $this->dateFormatterPrototype->getTimeType(); always evaluates to (This does explain why twigphp/intl-extra#6 was never noticed.) |
Sorry about spamming in here, but I did want to point out another flaw in the current implementation. Allow me to quote myself from twigphp/intl-extra/pull/6:
|
The 2nd patch in twigphp/intl-extra/pull/6 seems sensible to me and solves this issue. What do you think, @stof? |
I've found another issue which is very related to the current one. I'm fine creating a separate issue if you want. Consider $twig->addExtension(new IntlExtension(
new IntlDateFormatter(
'nl_NL',
IntlDateFormatter::MEDIUM, IntlDateFormatter::MEDIUM,
new DateTimeZone('Europe/Amsterdam')
)
));
I'd expect the explicit date and time types ( If you agree that's a bug then I'd be happy to create a patch. I'd propose only using the prototype's pattern only diff --git a/IntlExtension.php b/IntlExtension.php
index f8537c3..d941b76 100644
--- a/IntlExtension.php
+++ b/IntlExtension.php
@@ -338,7 +338,13 @@ final class IntlExtension extends AbstractExtension
$timeFormatValue = $timeFormatValue ?: $this->dateFormatterPrototype->getTimeType();
$timezone = $timezone ?: $this->dateFormatterPrototype->getTimeZone()->toDateTimeZone();
$calendar = $calendar ?: $this->dateFormatterPrototype->getCalendar();
- $pattern = $pattern ?: $this->dateFormatterPrototype->getPattern();
+ if ('' === $pattern) {
+ if (!$dateFormat && !$timeFormat) { // no explicit values for either format given
+ $pattern = $this->dateFormatterPrototype->getPattern();
+ } else {
+ $pattern = null;
+ }
+ }
}
$hash = $locale.'|'.$dateFormatValue.'|'.$timeFormatValue.'|'.$timezone->getName().'|'.$calendar.'|'.$pattern; |
It uses the PHP default timezone as the default configuration. But if you change the config in CoreExtension, the default timezone of Twig is now |
What's your point exactly?
I'd argue that "bare" date(time) strings (which lack an offset) should be interpreted as being in the currently configured timezone - which is whatever This is actually already the case!
This isn't happening for string dates. (It does work for Here's example to prevent miscommunication: date_default_timezone_set($systemTimezone);
// and / or
CoreExtension::setTimezone($systemTimezone);
$twig->addExtension(new IntlExtension(
new IntlDateFormatter($userTimezone) // wrong parameter config for brevity
));
$twig->render(" // invalid, but you get the idea
{{ '2020-02-02 13:37'|format_datetime() }}
"); I'd argue that the datetime string should be parsed/instantiated as being in Do you disagree? |
Oh, and any comment on the other issues I've found would be greatly appreciated. Would you like separate issues for each? On this repo or on |
It appears that the same is happening for |
Due to the lack of feedback, we (@dsuurlant and me) will continue working on all the issues presented here in our fork of the I hope that helps anyone running into the same issues in the future. While I certainly agree that twig shouldn't break backwards compatibility, the |
format_datetime
doesn't convert timezone according to IntlDateFormatterext-intl
's use of IntlDateFormatter prototype has several bugs
ext-intl
's use of IntlDateFormatter prototype has several bugs
\Twig\Extra\Intl\IntlExtension
's constructor takes an optionalIntlDateFormatter
prototype. That works great for settings various defaults (dateType, timeType, pattern
), but it doesn't enable automatic timezone conversion.IntlDateFormatter
Consider this plain PHP example:
This automatically formats the UTC datetime using Amsterdam time. Neat!
twig/intl-extra
new IntlExtension(new IntlDateFormatter(/* ... */))
however doesn't apply the timezone, unfortunately.Why not?
IntlExtension::formatDateTime
lets\twig_date_converter
create aDateTime
usingCoreExtension::getTimezone()
and passes its timezone toIntlExtension::createDateFormatter()
- even when no timezone was passed toformatDateTime
.Passing in an explicit
$timezone
tocreateDateFormatter()
makes the method use that value instead of$this->dateFormatterPrototype->getTimeZone()
. (which is actually broken - see twigphp/intl-extra#6 ;p).Quirky workaround
Maybe users are supposed to
In that case though, date strings are not converted at all:
DateTime
objects are converted.The text was updated successfully, but these errors were encountered: