Skip to content
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

Closed
dhensby opened this issue Jun 10, 2015 · 6 comments
Closed

Regression i18n::get_date_format no longer takes locale into account #4267

dhensby opened this issue Jun 10, 2015 · 6 comments

Comments

@dhensby
Copy link
Contributor

dhensby commented Jun 10, 2015

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.

@dhensby dhensby added this to the 3.2 milestone Jun 10, 2015
@tractorcow
Copy link
Contributor

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.

@tractorcow tractorcow modified the milestones: 3.3.0, 3.2.0 Jun 16, 2015
@dhensby
Copy link
Contributor Author

dhensby commented Aug 28, 2015

seems bizarre as it's not internationalised any more...

@tractorcow
Copy link
Contributor

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.

@chillu
Copy link
Member

chillu commented Aug 30, 2015

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.

@tractorcow
Copy link
Contributor

Then, not easy :D

Also removing 3.3 milestone, since it won't be done by then.

@tractorcow tractorcow removed this from the 3.3.0 rc1 milestone Jan 21, 2016
@chillu
Copy link
Member

chillu commented Feb 16, 2017

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

@chillu chillu closed this as completed Feb 16, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants