How to make Django's "DATETIME_FORMAT" active?

Question

Where should DATETIME_FORMAT be placed for it to have effect on the display of date-time in the Django admin site (Django’s automatic admin interface)?

Documentation for DATETIME_FORMAT, on page http://docs.djangoproject.com/en/1.0/ref/settings/, says:

"The default formatting to use for datetime fields on
Django admin change-list pages -- and, possibly, by
other parts of the system."

Update 1: DATETIME_FORMAT is broken (the value of it is ignored), despite the documentation. Many years ago it worked, but since then the Django implementations have been broken wrt. this feature. It seems the Django community can't decide how to fix it (but in the meantime I think they should remove DATETIME_FORMAT from the documentation or add a note about this problem to it).

I have put these lines into file "settings.py" of the website/project (not the app), but it does not seem to have any effect (after restarting the development server):

DATETIME_FORMAT = 'Y-m-d H:i:sO'

DATE_FORMAT = 'Y-m-d'

As an example "June 29, 2009, 7:30 p.m." is displayed when using Django admin site.

Django version is 1.0.2 final and Python version is 2.6.2 (64 bit). Platform: Windows XP 64 bit.

Stack Overflow question European date input in Django Admin seems to be about the exact opposite problem (and thus an apparent contradiction).

The full path to file "settings.py" is "D:\dproj\MSQall\website\GoogleCodeHost\settings.py". I now start the development server this way (in a Windows command line window):

cd D:\dproj\MSQall\website\GoogleCodeHost

set DJANGO_SETTINGS_MODULE=GoogleCodeHost.settings

python manage.py runserver 6800

There is no difference. Besides these are positively read from file "settings.py":

DATABASE_NAME

INSTALLED_APPS

TEMPLATE_DIRS

MIDDLEWARE_CLASSES

"django-admin.py startproject XYZ" does not create file "settings.py" containing DATETIME_FORMAT or DATE_FORMAT. Perhaps there is a reason for that?

The sequence "d:", "cd D:\dproj\MSQall\website\GoogleCodeHost", "python manage.py shell", "from django.conf import settings", "settings.DATE_FORMAT", "settings.DATETIME_FORMAT" outputs (as expected):

'Y-m-d H:i:sO'
'Y-m-d'

So the content of file "settings.py" is being read, but does not take effect in the Django Admin interface.

Eridanus

Do you have the settings.py designated as settings module? docs.djangoproject.com/en/dev/topics/settings/… – Gangling

https://mcmap.net/q/156363/-how-can-i-change-the-default-django-date-template-format might be a dupe to this, but the question there is less precise – Montparnasse

Answer 1

This will solve the particular problem that is not possible with DATETIME_FORMAT (as it is ignored in the current Django implementations despite the documentation), is dirty too and is similar to ayaz's answer (less global - will only affect the admin site list view):

Right after the line

(date_format, datetime_format,time_format) = get_date_formats()

in file (Django is usually in folder Lib/site-packages in the Python installation)

django/contrib/admin/templatetags/admin_list.py

overwrite the value of datetime_format (for a models.DateTimeField in the model):

datetime_format = 'Y-m-d H:i:sO'

And for date-only fields:

date_format = 'Y-m-d'

Restart of the web-server (e.g. development server) or logging out of the admin interface is NOT necessary for this change to take effect. A simple refresh in the web-browser is all what is required.

Eridanus

Good god... also Denmark fame link is broken – Impeachable

Answer 2

With:

USE_L10N = False

DATE_TIME takes effect, since the localization of l10n overrides DATETIME_FORMAT and DATE_FORMAT as documented at: https://docs.djangoproject.com/en/1.9/ref/settings/#date-format

Montparnasse

Answer 3

As Ciro Santilli told, localization format overrides DATETIME_FORMAT in settings when USE_L10N = True. But you can still override DATETIME_FORMAT and other date/time formats by creating custom format files as described in Django documentation.

See detailed answer here.

You can override DATE_FORMAT, DATETIME_FORMAT, TIME_FORMAT and other date/time formats when USE_L10N = True by creating custom format files as described in Django documentation.

In summary:

1. Set FORMAT_MODULE_PATH = 'yourproject.formats' in settings.py
2. Create directory structure yourproject/formats/en (replacing en with the corresponding ISO 639-1 locale code if you are using other locale than English) and add __init__.py files to all directories to make it a valid Python module
3. Add formats.py to the leaf directory, containing the format definitions you want to override, e.g. DATE_FORMAT = 'j. F Y'.

Example from an actual project here.

Seymore

Answer 4

The two setting directives should be defined in settings.py. Could you ensure that the same settings.py that you are editing is being read when you start the development server?

You could always drop to the Python interactive shell by running python manage.py shell, and run these commands to ensure whether the date/time format values are getting through fine:

from django.conf import settings
settings.DATE_FORMAT
settings.DATETIME_FORMAT

Ok, I forgot to look it up, but ticket #2203 deals with this. Unfortunately, the ticket remains in pending state.

I remember that for a project that used a certain trunk revision of the 0.97 branch of Django, I worked around that by overwriting the date_format and datetime_format values in the get_date_formats() function inside django/utils/translation/trans_real.py. It was dirty, but I had already been using a custom Django of sorts for that project, so didn't see anything going wrong in hacking it trifle more.

Russell

Answer 5

According to my experiments with Django 4.2.1, DATETIME_FORMAT for DateTimeField() works only in Django Templates. In addition, DATE_FORMAT for DateField() and TIME_FORMAT for TimeField() work in Django Templates. *You can see my question explaining it.

And, DATE_INPUT_FORMATS for DateTimeField() and DateField() and TIME_INPUT_FORMATS for DateTimeField() and TimeField() work in Django Admin. *DATETIME_INPUT_FORMATS doesn't work to any parts of a Django project and you can see my question explaining it.

*You need to set USE_L10N False in settings.py to make these settings above work because USE_L10N is prior to them.

Borne