-
Notifications
You must be signed in to change notification settings - Fork 824
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
Regression i18n::get_date_format no longer takes locale into account #4267
Comments
It looks like it was done intentionally in #2841 to prevent an issue with frontend date formats. I'm not sure this can be put back without the bug in place. Maybe we should just look at this in 3.3. |
seems bizarre as it's not internationalised any more... |
Internationalisation is hard. If you can get it working again, without breaking validation, then sure. ;) I've already broken NumericField by trying to get it to work properly with international formats. |
It makes date and time formatting opt-in, with a reasonable default (ISO standard). You can set the date format both globally via YAML, and on a user/profile basis in the CMS. There's just too much magic in the Zend date mappings, and it breaks cases like client vs. server month selection (see rationale in #2841). Also, the date formats in Zend for "short" or "long" don't always make sense for user input - depending on the locale, they include short month names rather than numbers, which means users have to guess how they're shortened (or use the date picker). So if you try to bring localisation back in, please explain how you'll resolve the issues above, and check that edge cases like danish localisation still work. |
Then, not easy :D Also removing 3.3 milestone, since it won't be done by then. |
6906c9b was commited in Feb 2014, and released with 3.3. It's technically a semver violation, but I don't see how changing it back for 3.x releases is benefitting anyone at this point - and I stand by my reasoning that relying on Zend's inconsistent locale formatting isn't a good framework default (unpredictable shortened month names etc). We're also planning to use default browser date localisation in 4.x, which will make this problem less prominent: #6626 |
In 3.2.x-dev the get_date_format doesn't take the locale into account when returning the date format.
Instead, it is hard coded into the class via the
Config
.The text was updated successfully, but these errors were encountered: