#27981 closed Bug (fixed)
date/time filter docs inaccurate about how localization works
Reported by: | Erdem Yılmaz | Owned by: | nobody |
---|---|---|---|
Component: | Documentation | Version: | 1.10 |
Severity: | Normal | Keywords: | template date filter |
Cc: | Triage Stage: | Accepted | |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
In the django documentation it says about date filter
When used without a format string:
{{ value|date }}
...the formatting string defined in the DATE_FORMAT setting will be used, without applying any localization.
my DATE_FORMAT in the settings.py is as follows:
DATE_FORMAT = 'd-F-Y'
But my DATE_FORMAT setting is not used, the locale-dictated format (DATE_FORMAT = 'd F Y') always overrides my custom format which contains dashes
Change History (11)
comment:1 by , 8 years ago
Component: | Template system → Documentation |
---|---|
Summary: | date filter localization problem → date/time filter docs inaccurate about how localization works |
Triage Stage: | Unreviewed → Accepted |
comment:3 by , 8 years ago
I want to ask why the change in #25758 shouldn't be reverted? I think if I set the settings.DATE_FORMAT it should be higher precendence then the locale dictated format in the date filter. Actually i think if i set the settings.DATE_FORMAT, all of the date fields in any part of the system should be displayed with this format instead of locale dictated one without applying the date filter. What is the reason of the locale-dictated format has higher precedence than the specified setting.DATE_FORMAT?
comment:4 by , 8 years ago
Erdem, because when USE_L10N
is True, all dates and numbers are now consistently localized by default. To prevent localization, you should be able to:
- set
USE_L10N
toFalse
to deactivate localization site-wide. - use the localize template tag to deactivate localization at specific places.
- add a custom setting for your application and pass that setting to the
date
filter.
If you can provide a use case which is not covered by these abilities, please develop.
follow-up: 6 comment:5 by , 8 years ago
I just wanted to use localization and at the same time set a specific DATE_FORMAT option instead of the locale one. Your second and third
approaches can be used but they are not too useful beacuse I should find all date occurances and apply some filters, which is not a general system wide solution https://docs.djangoproject.com/en/1.10/topics/i18n/formatting/#creating-custom-format-files This custom format file structure helped me. Thanks
I just curious about why when USE_L10N is True, all dates and numbers are now consistently localized by default even if some format setting (DATE_FORMAT, TIME_FORMAT etc.) is present. In my opininon setting something explicitly in the settings.py should have higher precedence than a locale format
follow-up: 7 comment:6 by , 8 years ago
I just curious about why when USE_L10N is True, all dates and numbers are now consistently localized by default even if some format setting (DATE_FORMAT, TIME_FORMAT etc.) is present. In my opininon setting something explicitly in the settings.py should have higher precedence than a locale format
DATE_FORMAT
and TIME_FORMAT
always have a value from the global settings (for the case where USE_L10N
is False). So Django cannot know if the settings are redefined at project level.
comment:7 by , 8 years ago
Replying to Claude Paroz:
I just curious about why when USE_L10N is True, all dates and numbers are now consistently localized by default even if some format setting (DATE_FORMAT, TIME_FORMAT etc.) is present. In my opininon setting something explicitly in the settings.py should have higher precedence than a locale format
DATE_FORMAT
andTIME_FORMAT
always have a value from the global settings (for the case whereUSE_L10N
is False). So Django cannot know if the settings are redefined at project level.
I'm curious about the case where USE_L10N is True
comment:8 by , 8 years ago
The documentation for DATE_FORMAT and similar is clear about the behavior, "if USE_L10N
is set to True
, then the locale-dictated format has higher precedence and will be applied instead."
From a quick look, this decision dates to the introduction of the USE_L10N
setting in 9233d0426537615e06b78d28010d17d5a66adf44 (#7980).
It looks like this was an intentional change in #25758. Assuming that change shouldn't be reverted, the documentation should be updated as well as release notes for 1.10 added.