Store datetime as UTC and change how Django handles datetime objects
|Reported by:||George Song||Owned by:||nobody|
|Component:||Database layer (models, ORM)||Version:||1.0|
|Has patch:||no||Needs documentation:||no|
|Needs tests:||no||Patch needs improvement:||no|
The way Django handles datetime right now makes developing time zone aware applications unnecessarily hard.
I've been doing some research and some thinking about this issue, mainly from these two tickets:
How it is right now
As I understand it right now, this is how datetime works in Django:
- For anything that implements
time.tzset(), Django sets the timezone for the entire runtime to
settings.TIME_ZONE. This means on Windows the setting is ignored. Django on Windows will operate in whatever timezone is specified on the OS.
- EXCEPT in the case of PostgreSQL backend, where the db connection initializes with
cursor.execute("SET TIME ZONE %s", [settings.TIME_ZONE]). Since
timefields are created
with time zone, this means PostgreSQL will return datetime values typecasted to
- Django typecasts everything to naive Python
This blog post is a good overview of how Rails handles time zone support: http://mad.ly/2008/04/09/rails-21-time-zone-support-an-overview/
- PostgreSQL should not have time zone set, or have time zone set to 'UTC'.
- Django should store all datetime on DB backends as naive UTC datetime.
settings.TIME_ZONEbecomes a site-wide runtime typecast directive. This way
settings.TIME_ZONEcan be optional if someone doesn't care about time zones in their application. In that case it feels more natural to operate in the timezone of the server hosting Django. The default return from
from django.conf import settings from django.db.backends.util import typecast_timestamp from dateutil.tz import tzutc, tzstr, tzlocal utc = tzutc() server_tz = tzlocal() settings_tz = None if settings.TIME_ZONE: settings_tz = tzstr(settings.TIME_ZONE) utc_dt = typecast_timestamp(db_value).replace(tzinfo=utc) if settings_tz == utc: dt = utc_dt elif settings_tz: # Cast it to the specified timezone dt = utc_dt.astimezone(settings_tz) else: # Cast to server local time then make it naive dt = utc_dt.astimezone(server_tz).replace(tzinfo=None) return dt
- On the way back into the database, Django can do something like:
from django.conf import settings from dateutil.tz import tzutc, tzstr utc = tzutc() server_tz = tzlocal() settings_tz = None if settings.TIME_ZONE: settings_tz = tzstr(settings.TIME_ZONE) dt = dt_value_from_model_save if dt.tzinfo: pass # It's a smart date, do nothing. elif settings_tz: dt = dt.replace(tzinfo=settings_tz) else: # Default to server time zone dt = dt.replace(tzinfo=server_tz) dt = dt.astimezone(utc).replace(tzinfo=None) # Now save dt into the database
- I think the following convenience
DateTimeFieldinstance methods or attributes might be nice:
datetime.datetimeobject in UTC, no
datetime.datetimeobject in UTC, with
posix_timestamp: returns the POSIX timestamp as float, such as is returned by
time.time(), with the exception that microsecond precision should be retained
astimezone(tzinfo): might be convenient for those who operate in naive datetime mode most of the time, but have specific places where time zones are important
- Django doesn't have to change the entire runtime with
- Windows servers acts just like Unix servers.
- I don't think this will break standard application code, since
settings.TIME_ZONEessentially functions the same way as before, except your
datetimeobjects will have
- For those dealing with time zones, UTC underneath the hood!
- If you want UTC everything while working inside Django,
- If you don't care about time zones,