ValueError: astimezone() cannot be applied to a naive datetime

[warrengray]

Hello, it appears that the fix applied to resolve #82 is triggering an error in our environment. I've included a partial stack trace below.

Django 1.8 is configured with the following timezone settings:

TIME_ZONE = 'UTC'
USE_TZ = True

Partial stack trace:

  File "/usr/local/lib/python2.7/dist-packages/django/db/models/base.py", line 710, in save
    force_update=force_update, update_fields=update_fields)
  File "/usr/local/lib/python2.7/dist-packages/django/db/models/base.py", line 747, in save_base
    update_fields=update_fields, raw=raw, using=using)
  File "/usr/local/lib/python2.7/dist-packages/django/dispatch/dispatcher.py", line 201, in send
    response = receiver(signal=self, sender=sender, **named)
  File "/usr/local/lib/python2.7/dist-packages/auditlog/receivers.py", line 16, in log_create
    changes = model_instance_diff(None, instance)
  File "/usr/local/lib/python2.7/dist-packages/auditlog/diff.py", line 131, in model_instance_diff
    new_value = get_field_value(new, field)
  File "/usr/local/lib/python2.7/dist-packages/auditlog/diff.py", line 69, in get_field_value
    value = timezone.make_naive(value, timezone=timezone.utc)
  File "/usr/local/lib/python2.7/dist-packages/django/utils/timezone.py", line 376, in make_naive
    value = value.astimezone(timezone)
ValueError: astimezone() cannot be applied to a naive datetime

Our model definition:

class InventoryAsset(Model):
  created = DateTimeField()

In this case, it looks like our timestamp is already naive? I haven't yet checked out the code, but I suspect the quick fix is first checking to see if the value is already naive. I will keep this issue updated if I discover anything else.

[warrengray]

In our case, we're setting the field via datetime.utcnow(), which generates a naive datetime object (I'm actually not sure we're doing this correctly now that I think about it), which is what's getting saved in the created attribute. I think it's a happy coincidence that our system only operates in UTC, and thus we don't notice any time skews.

[jjkester]

Good spot. I think if you have USE_TZ=True in your settings you should always tag your datetimes with the time zone. Nevertheless, the fix clearly assumes a non-naive datetime object. I think a simple check whether the datetime is naive or not would fix this.

If you are (or anyone else is) interested in writing a pull request that would be appreciated. Otherwise I will fix this myself at some point.

[audiolion]

Closed in #144