﻿id	summary	reporter	owner	description	type	status	component	version	severity	resolution	keywords	cc	stage	has_patch	needs_docs	needs_tests	needs_better_patch	easy	ui_ux
10587	Store datetime as UTC and change how Django handles datetime objects	George Song	nobody	"== Problem ==

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: 

 * ticket:2626
 * ticket:1480

== How it is right now ==

As I understand it right now, this is how datetime works in Django:

 1. 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. 

 2. '''EXCEPT''' in the case of PostgreSQL backend, where the db connection initializes with `cursor.execute(""SET TIME ZONE %s"", [settings.TIME_ZONE])`. Since `timestamp` and `time` fields are created `with time zone`, this means PostgreSQL will return datetime values typecasted to `settings.TIME_ZONE` first. 

 3. Django typecasts everything to naive Python `datetime` objects (no `tzinfo` attached). 

== Proposed solution ==

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/

 1. PostgreSQL should not have time zone set, or have time zone set to 'UTC'.

 2. Django should store all datetime on DB backends as '''naive UTC''' datetime.

 3. `settings.TIME_ZONE` becomes a site-wide runtime typecast directive. This way `settings.TIME_ZONE` can 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 `model.some_datetime_field` could be: 
 
{{{
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
}}}

 4. 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
}}}

 5. I think the following convenience `DateTimeField` instance methods or attributes might be nice:

    * `naive_utc`: returns `datetime.datetime` object in UTC, no `tzinfo`
    * `utc`: returns `datetime.datetime` object in UTC, with `tzinfo`
    * `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

== Benefits ==

 1. Django doesn't have to change the entire runtime with `os.environ['TZ']` or `time.tzset()`.

 2. Windows servers acts just like Unix servers.

 3. I don't think this will break standard application code, since `settings.TIME_ZONE` essentially functions the same way as before, except your `datetime` objects will have `tzinfo` attached.

 4. For those dealing with time zones, '''UTC''' underneath the hood!

 5. If you want UTC everything while working inside Django, `settings.TIME_ZONE='UTC'`.

 6. If you don't care about time zones, `settings.TIME_ZONE=None`."		closed	Database layer (models, ORM)	1.0		duplicate		django@…	Unreviewed	0	0	0	0	0	0
