https://github.com/django-extensions/django-extensions/blob/master/django_extensions/db/fields/json.py#L26 causes assertion failures if the system timezone isn't UTC. It would be preferable to support datetime's native tz handling if e.g. pytz is installed rather than simply crashing.
In one use case I'd be storing datetime.datetime.utcnow() values in a JSONField and later comparing those against one another. I don't think that settings.TIME_ZONE would even have any effect in this case.
Maybe a warning about timezone issues in the documentation would suffice?
It's also somewhat annoying that this breaks when you set settings.TIME_ZONE to None and the machine's timezone is set to UTC.
I've proposed the following solution within our group - how does this sound? I thought about using pytz but I think this simple approach of requiring that the user either provide non-naive datetime instances or that the system time zone be UTC is sufficient:
# See http://docs.python.org/library/datetime.html
from datetime import tzinfo, timedelta, datetime
ZERO = timedelta(0)
HOUR = timedelta(hours=1)
def utcoffset(self, dt):
def tzname(self, dt):
def dst(self, dt):
utc = UTC()
def default(self, obj):
if isinstance(obj, Decimal):
elif isinstance(obj, datetime.datetime):
if obj.tzinfo is None:
assert settings.TIME_ZONE == 'UTC'
obj = obj.astimezone(utc)
return simplejson.JSONEncoder.default(self, obj)
JSONField: handle non-UTC dates (closes #95)
Extends the JSONField implementation to allow arbitrary timezones
as long as the user passes in non-naive datetime instances. Naive
values are still handled as in the past, requiring
settings.TIME_ZONE to be UTC.
Minor PEP8 cleanup
@acdha django already handles this, recently it was integrated into django-extensions, so it now uses it by default.
Seems you can close this issue.
@camilonova Was that added in Django 1.5 or 1.6? It does sound like we could simply close this either way since the release schedule for 1.6 and 1.7 is pretty aggressive and there's less reason to say django-extensions needs to care about anything which is more than one or two major releases back.
@acdha thats right, it was added in Django 1.5 so seems reasonable to close this issue.