Take the 2-minute tour ×

I suppose time zone management was addded to django 1.4, so the problem is quite new.

I used a simple model

class Sample(models.Model):
    date_generated = models.DateTimeField(auto_now_add = True)

When I try to retrieve a newly created record its fails.

min_datetime = datetime.now() - timedelta(seconds = 300)
sample = Sample.objects.get(date_generated__gte = min_datetime)

and the server issues a warning.

DateTimeField received a naive datetime (2012-06-29 15:02:15.074000) while time zone support is active.

I figured out two solutions to that problem.

  1. Disable time zone management in settings.py

    USE_TZ = False 

    but this is not always desierable.

  2. changing

    date_generated = models.DateTimeField(auto_now_add = True) 


    date_generated = models.DateTimeField(default=datetime.now()) 

    is the solution that keeps time zone management working

share|improve this question

2 Answers 2

The problem is on your end: datetime.now() is not TZ aware, so you're the one feeding in a naive TZ. See the Django docs on this issue. The reason it works when setting default=datetime.now is that you're forcing the value to a naive datetime, so when you later compare it with another naive datetime, there's no problem.

You need to get "now" the following way:

import datetime
from django.utils.timezone import utc

now = datetime.datetime.utcnow().replace(tzinfo=utc)
share|improve this answer
Does this mean I can't just use auto_now or auto_now_add if I have USE_TZ = True? –  dannyroa Jul 11 '12 at 19:46
It seems auto_now and auto_now_add inherently use datetime.now. It seems an odd omission on Django's part to insert TZ aware facilities into Django, yet miss this pretty major one, but the fate of these two kwargs has been debated for a long time. My reasoning is that they're being left in for backwards compatibility (and to avoid push-back), but don't expect them to get any love. Just set the default kwarg with utcnow and don't worry about auto_now or auto_now_add, if you want TZ aware datetimes. –  Chris Pratt Jul 11 '12 at 20:05
Thanks Chris. I don't think "default" would work in replacing "auto_now" though since the latter always update the time for every save while "default" is only when the field has no value. –  dannyroa Jul 11 '12 at 21:15
An even faster way to get "now"... from django.utils.timezone import now as utcnow. now = utcnow() will then give you the same result as @ChrisPratt gave. –  Ben Rosnick Dec 28 '12 at 3:03
django 1.4.5 shows auto_now or auto_now_add uses timezone.now() , not datetime.now() so its safe to use them. –  eugene Jul 16 '13 at 3:51

Be careful setting a DateTimeField default value of datetime.now(), as that will compute a single value when Apache/nginx loads Django (or when you start the development server), and all subsequent records will receive that value.

Always use auto_now_add for that reason.

share|improve this answer
Just use default=datetime.now without brackets. –  Nikolay Baluk Mar 9 at 14:06

Your Answer


