Django converts the timezone of DateTimeFields to UTC when the field gets saved. This makes it so when you update a model which includes a DateTimeField, and your server is running in another timezone, the AuditLog will think you changed the timestamp, while it actually is the same time, but in another timezone. This commit adds a specific check in the model_instance_diff function for DateTimeField models (and any subclasses of it), which converts the old and new values to UTC before comparing them to see if they've actually changed. It also adds tests to see if the code works properly.
The extra test_setting (USE_TZ) is added because timezone support is disabled if it is not specified, this setting enables it.
Seq Scan on auditlog_logentry on heroku postgres. I suspect because of missing index.
````
SELECT "auditlog_logentry"."id", "auditlog_logentry"."content_type_id", "auditlog_logentry"."object_pk", "auditlog_logentry"."object_id", "auditlog_logentry"."object_repr", "auditlog_logentry"."action", "auditlog_logentry"."changes", "auditlog_logentry"."actor_id", "auditlog_logentry"."remote_addr", "auditlog_logentry"."timestamp", "auditlog_logentry"."additional_data" FROM "auditlog_logentry" WHERE ("auditlog_logentry"."content_type_id" = %s AND "auditlog_logentry"."object_pk" = %s)
```
the Django warning:
site-packages/auditlog/middleware.py:9: RemovedInDjango19Warning: The utilities in django.db.models.loading are deprecated in favor of the new application loading system.
from django.db.models.loading import get_model
to remove the following Django Warning:
site-packages/auditlog/models.py:6: RemovedInDjango19Warning:
django.contrib.contenttypes.generic is deprecated and will be
removed in Django 1.9. Its contents have been moved to the
fields, forms, and admin submodules of
django.contrib.contenttypes.
from django.contrib.contenttypes import generic
