date and time filters do not use localized strings, missing datetime filter

[Bob Thomas]

The date and time filters do not use localized/translated strings for the default format. The admin interface uses get_date_formats, which checks for a translation first, then falls back to settings.DATE_FORMAT, etc.

Also, a filter that defaults to DATETIME_FORMAT is missing, and would be a nice shortcut.

[Bob Thomas]

Use translated strings for date/time formats, add a datetime filter

[Malcolm Tredinnick]

One item per ticket, please. You're both trying to report a bug and add a new feature here. I suspect the new feature probably won't go in, since you can already format datetimes with the date filter and we should just the right default there (whatever that is).

So please split out the new feature bit from this patch so the bugfix can be considered in isolation (it also will need a test). If you want to open a new ticket for the new feature, that's fine and it can then be looked at in due course.

[Bob Thomas]

I think this is somewhat related to #2203 (the bug part of it, anyway). However that ticket is fixed will affect this, since the admin interface's date display should be consistent with the date filters.

[Daniel Pope <dan@…>]

@mtreddinick: This isn't really two items. This ticket is about the fact that there's no way of using the existing datetime localisation (​http://code.djangoproject.com/browser/django/trunk/django/utils/translation/trans_real.py#L396) in templates.

It makes sense to have the date and time filters do this if the i18n machinery is enabled - otherwise these filters are just about useless in internationalised applications. However, it's not sufficient to just have date and time filters, as the preferred format for combined time and date in different cultures may vary independently from date, time or any combination of the two, so the solution also necessitates a datetime filter. It's a two-part solution, not two different problems.

Anyway, FWIW, this is exactly what I need for the site I'm developing at the moment.

[Malcolm Tredinnick]

It is about two items. Item #1 is the first paragraph of the description. Item #2 is the second paragraph. The second one is a feature request and is independent of the first part.

[Daniel Pope <dan@…>]

The second part is not independent. Imagine a culture that writes date as dd/mm/yyyy but date and time as dd/mm hh:mm yyyy. Whether any such culture exists I don't know, but an internationalisable datetime formatting system should be able to cope with this.

[Malcolm Tredinnick]

You are simply saying that the second feature is necessary. Not that it is entirely and unrevocably part of the first bug fix. It will be quite possible to fix the first part without adding the second part. They are separable. This isn't a question of value.

In any case, this is going around and around. The internationalisation fix will be done as part of a larger ticket. At that point, somebody can update this with a fix to add the missing bit.

[Bob Thomas]

See discussion at ​http://groups.google.com/group/django-developers/browse_thread/thread/887fc3babda70418

[Jannis Leidel]

(In [11964]) Fixed #7980 - Improved i18n framework to support locale aware formatting (dates and numbers) and form processing.

Thanks to Marc Garcia for working on this during his Google Summer of Code 2009!

Additionally fixes #1061, #2203, #3940, #5526, #6449, #6231, #6693, #6783, #9366 and #10891.