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
--
Ticket URL: <https://code.djangoproject.com/ticket/27981>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
* component: Template system => Documentation
* stage: Unreviewed => Accepted
Comment:
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/27981#comment:1>
* has_patch: 0 => 1
Comment:
Suggested [https://github.com/django/django/pull/8243 PR].
--
Ticket URL: <https://code.djangoproject.com/ticket/27981#comment:2>
Comment (by Erdem Yılmaz):
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?
--
Ticket URL: <https://code.djangoproject.com/ticket/27981#comment:3>
Comment (by Claude Paroz):
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` to `False` to deactivate localization site-wide.
- use the
[https://docs.djangoproject.com/en/1.10/topics/i18n/formatting/#std
:templatetag-localize 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.
--
Ticket URL: <https://code.djangoproject.com/ticket/27981#comment:4>
Comment (by Erdem Yılmaz):
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
--
Ticket URL: <https://code.djangoproject.com/ticket/27981#comment:5>
Comment (by 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` 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.
--
Ticket URL: <https://code.djangoproject.com/ticket/27981#comment:6>
Comment (by Erdem Yılmaz):
Replying to [comment:6 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` 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.
I'm curious about the case where USE_L10N is True
--
Ticket URL: <https://code.djangoproject.com/ticket/27981#comment:7>
Comment (by Tim Graham):
The documentation for [https://docs.djangoproject.com/en/dev/ref/settings
/#date-format 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).
--
Ticket URL: <https://code.djangoproject.com/ticket/27981#comment:8>
* status: new => closed
* resolution: => fixed
Comment:
In [changeset:"6585ebebaaa58aeef45210a3119dbaa322f8baca" 6585ebe]:
{{{
#!CommitTicketReference repository=""
revision="6585ebebaaa58aeef45210a3119dbaa322f8baca"
Fixed #27981 -- Doc'd date/time filter l10n changes in refs #25758.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/27981#comment:9>
Comment (by Tim Graham <timograham@…>):
In [changeset:"28cf32b2cb4e6385102be3192aea414be402e1a1" 28cf32b]:
{{{
#!CommitTicketReference repository=""
revision="28cf32b2cb4e6385102be3192aea414be402e1a1"
[1.11.x] Fixed #27981 -- Doc'd date/time filter l10n changes in refs
#25758.
Backport of 6585ebebaaa58aeef45210a3119dbaa322f8baca from master
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/27981#comment:10>
Comment (by Tim Graham <timograham@…>):
In [changeset:"16b97a2cebff2d59d2aadf99b4a240cdc767d646" 16b97a2]:
{{{
#!CommitTicketReference repository=""
revision="16b97a2cebff2d59d2aadf99b4a240cdc767d646"
[1.10.x] Fixed #27981 -- Doc'd date/time filter l10n changes in refs
#25758.
Backport of 6585ebebaaa58aeef45210a3119dbaa322f8baca from master
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/27981#comment:11>