Opened 3 years ago

Closed 3 years ago

Last modified 2 years ago

#18769 closed Bug (invalid)

Despite selected language, Forms still rely on LANGUAGE_CODE to format datetime (demo included)

Reported by: houmie Owned by: nobody
Component: Internationalization Version: 1.4
Severity: Normal Keywords: formats, i18n, l10n
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no


I have discussed this issue in stackoverflow and it seems to be a bug.


In a nutshell, despite creating custom, only the templates react to the selected language while the forms still rely on LANGUAGE_CODE


I have created a small live demo to show the problem. Please open the demo here:

When you click on British English, you can see how both the date- and time format within the template change accordingly, which is great.

Now if you click on Add, you will see how both the current date and time are populated for you in the form. However they still carry the American date format, instead of the selected British language.

The only way to fix this is to change




in This approach would be obviously useless as its no longer dynamic and favors one group over the other. LANGUAGE_CODE should be the last priority since the selected language should have a higher priority. But this doesn't work when having custom for each language.

I have created custom to override the date and time formats for en and en_GB as described in the documentation so I am clueless what else I could do.

Please be so kind and download my demo (22 kb) from my dropbox ( or see attachment: All you have to do is to edit to adjust the path to sqlite.db.

Attachments (1) (22.4 KB) - added by houmie 3 years ago.
Sandbox demo (i18n problem)

Download all attachments as: .zip

Change History (4)

Changed 3 years ago by houmie

Sandbox demo (i18n problem)

comment:1 Changed 3 years ago by houmie

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Type changed from Uncategorized to Bug

comment:2 Changed 3 years ago by kmtracey

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

The form you are using hasn't specified to localize the fields. The file in the sandbox project has:

from django.forms.models import ModelForm
from Sandbox_App.models import Company

class CompanyForm(ModelForm):
    def date_callback(self, field, **kwargs) :
        return, **kwargs)
    def time_callback(self, field, **kwargs) :
        return field.time(localize=True, **kwargs)

    class Meta:
        model = Company

I gather it is expected that these callback functions will turn on localization for the fields, but I do not know where the idea for defining these callbacks came from. Django model forms do not call these functions, so they have no effect. Changing that file to:

from django import forms
from Sandbox_App.models import Company

class CompanyForm(forms.ModelForm):
    date = forms.DateField(localize=True)
    time = forms.TimeField(localize=True)

    class Meta:
        model = Company

results in the form on initial display being localized as per the chosen language.

comment:3 Changed 2 years ago by justinkhill@…

I'm having trouble getting my Canadian and Australian sites to use the correct date formatting via the localize=True method mentioned here. My other international sites are working correctly.

I've decided it is because there are no en_AU and en_CA files in the django core project:
Am I left to create my own as described here:

If so, so be it, but may I ask why such well know countries do not have their own in the core project? Am I doing it wrong?

Note: See TracTickets for help on using tickets.
Back to Top