Code

Opened 8 years ago

Closed 4 years ago

#2203 closed defect (fixed)

TIME_FORMAT, DATE_FORMAT and DATETIME_FORMAT are ignored

Reported by: marcink@… Owned by: garcia_marc
Component: Internationalization Version: master
Severity: normal Keywords: i18n-fixed
Cc: gonz Triage Stage: Fixed on a branch
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:

Description

Contrary to the docs at http://www.djangoproject.com/documentation/settings/,
changing TIME_FORMAT, DATE_FORMAT and DATETIME_FORMAT does not influence admin pages in any way.

These were added in [1115] but apparently got lost during magic-removal.

Attachments (1)

settings.py (2.7 KB) - added by bahamut@… 8 years ago.
Settings file for my application. Date and time formats are not respected in admin site.

Download all attachments as: .zip

Change History (26)

comment:1 Changed 8 years ago by ramiro

Hi,

What SVN revision are you using?. What behavior are you observing?.

Does the translated catalog you are using (pl.po?) specify these technical IDs
(TIME_FORMAT, DATE_FORMAT and DATETIME_FORMAT)?

This should be working, the code that appears in contrib/admin/views/main.py in the [1115] patchset
now lives in contrib/admin/templatetags/admin_list.py and calls the utils/translation.py:get_date_formats()
function. That function uses the fomat strings specified in your xx.po if any and fallback to the values specified in global-settings.py/your settings.py.

Seee also [3055]

comment:2 Changed 8 years ago by adrian

  • Resolution set to worksforme
  • Status changed from new to closed

Looks like it's a problem with your translation catalog.

comment:3 Changed 8 years ago by bahamut@…

  • Resolution worksforme deleted
  • Status changed from closed to reopened
  • Version set to SVN

This is broken as of r3327 trunk, for the English locale. Indeed, it seems to export or define time and date formats, which completely overwrites any project settings. This means there's no way to switch to 24 hours time, etc.

comment:4 Changed 8 years ago by adrian

bahamut: Would you perhaps be importing django.utils.translation in your settings file? See #2309 for discussion.

comment:5 Changed 8 years ago by bahamut@…

I am not. I'm attaching my settings file.

Changed 8 years ago by bahamut@…

Settings file for my application. Date and time formats are not respected in admin site.

comment:6 Changed 8 years ago by bahamut@…

I'm not sure how it can work intuitively -- that is, the date and time format settings applying to the admin site and other translated areas properly.

For example, taking the code from the admin site.

source:trunk/django/contrib/admin/templatetags/admin_list.py line 138

elif isinstance(f, models.DateField) or isinstance(f, models.TimeField):
                if field_val:
                    (date_format, datetime_format, time_format) = get_date_formats()
                    if isinstance(f, models.DateTimeField):
                        result_repr = capfirst(dateformat.format(field_val, datetime_format))
                    elif isinstance(f, models.TimeField):
                        result_repr = capfirst(dateformat.time_format(field_val, time_format))
                    else:
                        result_repr = capfirst(dateformat.format(field_val, date_format))

If we look at get_date_formats:

source:trunk/django/utils/translation/trans_real.py line 355

def get_date_formats():
    """
    This function checks whether translation files provide a translation for some
    technical message ID to store date and time formats. If it doesn't contain
    one, the formats provided in the settings will be used.
    """
    from django.conf import settings
    date_format = _('DATE_FORMAT')
    datetime_format = _('DATETIME_FORMAT')
    time_format = _('TIME_FORMAT')
    if date_format == 'DATE_FORMAT':
        date_format = settings.DATE_FORMAT
    if datetime_format == 'DATETIME_FORMAT':
        datetime_format = settings.DATETIME_FORMAT
    if time_format == 'TIME_FORMAT':
        time_format = settings.TIME_FORMAT
    return date_format, datetime_format, time_format

It would seem we'll always get the format from the translation files, not from the settings.

comment:7 Changed 8 years ago by bahamut@…

Might have wanted to preview that entry first :|

Correct source links are

  • source:django/trunk/django/contrib/admin/templatetags/admin_list.py line 138
  • source:django/trunk/django/utils/translation/trans_real.py line 355

comment:8 Changed 8 years ago by bahamut@…

I should also mention that, as of r3327, setting USE_I18N to False in your settings file will happily blow up the admin site, with the following exception being generated:

Exception Type: AttributeError
Exception Value: 'module' object has no attribute 'get_language_bidi'
Exception Location: /opt/local/lib/python2.4/site-packages/django/core/context_processors.py in i18n, line 41

This might be worth posting as a new ticket. However, this is a separate issue and I believe date and time formats should be configurable outside the scope or control of the localization files. There are arguably legitimate reasons for this (e.g. an application for the US military might require to use the 24 hours time format, while the locale would stil be en-us).

comment:9 Changed 8 years ago by anonymous

*sigh* I really need to start using the preview button...

Un-wikified exception details:

Exception Type:        AttributeError
Exception Value:       'module' object has no attribute 'get_language_bidi'
Exception Location:    /opt/local/lib/python2.4/site-packages/django/core/context_processors.py in i18n, line 41

comment:10 Changed 8 years ago by adrian

(In [3329]) Added get_language_bidi to django.utils.translation.trans_nuill. Refs #2203

comment:11 Changed 7 years ago by SmileyChris

  • Triage Stage changed from Unreviewed to Accepted

Looks valid to me.

Bahamut mentioned "It would seem we'll always get the format from the translation files, not from the settings." so could someone write up a patch to fix this?

comment:12 Changed 7 years ago by mtredinnick

  • Triage Stage changed from Accepted to Design decision needed

On one level, we *should* be getting the format from the translation files, in almost all cases. This is because the developer/designer of the original presentation is not going to be up to speed on all the subtleties and traditions of time presentation in all the locales, whereas the translator will know how times are normally presented in their particular language (and the translator and designer should be working together on the tricky cases).

So there is a design problem here: allowing control of time presentation information via the settings file does not interact well with localisation. I'm not sure what a solution is to this one yet, since I only just noticed this ticket. But it's not a clear bug, to my mind, at the moment. Needs some more thought.

The example of wanting to force time to always be in military time, for example, is a case where the timezone presentation in each case should be translated to use the 24-hour presentation. However, that is a separate issue in any case (since it enters the realm of project-wide translation files overriding core translations, which is something we cannot handle at the moment). So let's not have any more discussion of that in this ticket, please.

comment:13 Changed 6 years ago by garcia_marc

  • Keywords i18n-rf added

comment:14 Changed 6 years ago by garcia_marc

  • Component changed from Admin interface to Internationalization
  • milestone set to post-1.0

comment:15 Changed 6 years ago by lakin@…

In my mind this is a bug. My reasoning is as follows: In every language there are many different (but correct) ways in which to display a date. Although one way may be considered a default, surely there are many ways that are valid. In order to change the default date display on one app, I have to provide a custom translation?

comment:17 Changed 5 years ago by anonymous

  • milestone post-1.0 deleted

Milestone post-1.0 deleted

comment:18 Changed 5 years ago by sergey.g.aleshin@…

  • milestone set to 1.0.3

This bug is still in 1.0x.
How i can change date and time format for admin site but keep I18N settings?

comment:19 Changed 5 years ago by kmtracey

  • milestone 1.0.3 deleted

The triage state for this ticket is "Design decision needed". Something that needs design work is not a candidate for 1.0.3. You might consider asking your question on the django-users list; I do not know if there is any good answer but the audience there is far larger than here so you'd have a better chance of getting a useful answer.

comment:20 Changed 5 years ago by gonz

  • Cc gonz added

comment:21 Changed 5 years ago by garcia_marc

  • Keywords i18n-fixed added; i18n-rf removed
  • Owner changed from nobody to garcia_marc
  • Status changed from reopened to new

Fixed in branches/soc2009/i18n-improvements.

comment:22 Changed 5 years ago by garcia_marc

  • Triage Stage changed from Design decision needed to Fixed on a branch

comment:23 Changed 4 years ago by sorin

The irony is that even this Trac is not well configured - the dates are listed using US locale instead of something more word-ready like ISO 8601.

Also I strongly recommend to change the *defaults* to use ISO 8601.

When should we see this in trunk?

comment:24 Changed 4 years ago by ctao

If change the following code

    if date_format == 'DATE_FORMAT':
        date_format = settings.DATE_FORMAT
    if datetime_format == 'DATETIME_FORMAT':
        datetime_format = settings.DATETIME_FORMAT
    if time_format == 'TIME_FORMAT':
        time_format = settings.TIME_FORMAT

into

    if settings.DATE_FORMAT:
        date_format = settings.DATE_FORMAT
    if settings.DATETIME_FORMAT:
        datetime_format = settings.DATETIME_FORMAT
    if settings.TIME_FORMAT:
        time_format = settings.TIME_FORMAT

then it will use the format from setting.

comment:25 Changed 4 years ago by jezdez

  • Resolution set to fixed
  • Status changed from new to closed

(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.

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.