Buildin template tags seem to break i18n

[houmie]

Within my template as long as I have the following, the template automatically converts the datetime from UTC into my currently selected timezone. And I can also switch to a different culture (US to UK format) and the date and time format do change accordingly.

{% load l10n %}
{% for item in calls %}
     <td>{{ item.conversation_datetime }}</td>
     <td>{{ item.conversation_datetime }}</td>
{% endfor %}

Now all I need to do is to extract the localized date for the former and localized time for the latter. So I thought lets bang a template tag in there and life is good.

{% load l10n %}
{% for item in calls %}
     <td>{{ item.conversation_datetime|date }}</td>
     <td>{{ item.conversation_datetime|time }}</td>
{% endfor %}

But if life was good, I wouldn't be sitting here and writing this would I? ;) The moment these filters are set, the format for these two fields seems to be fixed to the US culture. Date format is mm/dd/yyyy and time is 12 hrs am/pm.

Selecting the British language as I did before successfully has no longer any effect.

Please see a demo attached to this ticket.

[houmie]

In the demo, simply change the Language to British English, and you would see right away, that the latter two fields change the date format, while the former two fields with |date tag, stay as nothing had changed...

[Claude Paroz]

Isn't this documented?: ​https://docs.djangoproject.com/en/dev/ref/templates/builtins/#date

Quoted:

When used without a format string:

{{ value|date }}

...the formatting string defined in the DATE_FORMAT setting will be used, without applying any localization.

[houmie]

Thanks for your feedback.

Well I have already overridden the formats.py for both American and British (you can see that in the attached demo). Therefore upon changing the language, the best would be if the current language's formatting is picked up from formats.py.

Otherwise if I had to pass a format string to the template it will be hardcoded in the template and the whole purpose of formats.py is gone through the wind. Since the moment the user changes the language, the formatting would change accordingly and hence the latter can't be hardcoded into the template.

|date and |time are very useful to extract the data from a single date time field in the template. Therefore shouldn't they respect localization and timezones respectively?

If you agree to this I have changed the type of this ticket to 'New Feature'.
Hopefully this can be implemented, as its very useful to have.

Many Thanks,

[Claude Paroz]

It is known that I'm sometimes slow to understand :-) I still don't get where the problem is.

Either:

1. You want to hardcode the format in templates: use a format string (|date:"Y-m-d")
2. You want to hardcode the format from settings (project-dependent): use the raw filter (|date)
3. You want the format depending on the language; use a predefined format (|date:"DATE_FORMAT")

Please tell me what I missed here.

[houmie]

Sorry for late reply. Don't worry I don't think you are slow, more likely I am not explaining well enough. :)

For your convenience I have attached a screenshot of my demo to discuss it here.

In the example if I use item.conversation_datetime I would get the British dateformat coming from my overriden formats.py: 30 August 2012, 21:33

However the moment I extract only the date and time with |date & |time accordingly I would loose the localization. As you can see from the screenshot the date has the American date format.

Now that we agree upon the problem, lets investigate your suggested solutions:

1) and 2) are hardcoded and won't be good in my case as I need the user to be able to change the language at any time.

3) You want the format depending on the language; use a predefined format (|date:"DATE_FORMAT")

Yes, this is the solution. I didn't know this is possible. This way you extract the "DATE_FORMAT" from formats.py same for time: |time:"TIME_FORMAT". This was exactly what I was looking for. I am so sorry I couldn't see this bit in the documentation.

Your help was highly appreciated to solve this issue.

[Claude Paroz]

Happy end :-)