Supongo que la administración de zona horaria se agregó a django 1.4, por lo que el problema es bastante nuevo.Cómo funciona la zona horaria de django con model_field's auto_now_add
que utiliza un modelo simple
class Sample(models.Model):
...
date_generated = models.DateTimeField(auto_now_add = True)
Cuando intento para recuperar un registro recién creado su falla.
min_datetime = datetime.now() - timedelta(seconds = 300)
sample = Sample.objects.get(date_generated__gte = min_datetime)
y el servidor emite una advertencia.
DateTimeField received a naive datetime (2012-06-29 15:02:15.074000) while time zone support is active.
Encontré dos soluciones para ese problema.
Desactivar control de zonas horarias en settings.py
USE_TZ = False
pero esto no siempre es desierable.
cambiar
date_generated = models.DateTimeField(auto_now_add = True)
a
date_generated = models.DateTimeField(default=datetime.now())
es la solución que mantiene control de zonas horarias de trabajo
¿Esto significa que no sólo puede utilizar auto_now o auto_now_add si tengo USE_TZ = verdad? – dannyroa
Parece que 'auto_now' y' auto_now_add' usan inherentemente 'datetime.now'. Parece una extraña omisión por parte de Django insertar instalaciones conscientes de TZ en Django, sin embargo, se pierda esta muy importante, pero el destino de estos dos kwargs ha sido debatido durante mucho tiempo. Mi razonamiento es que se les deja en compatibilidad retroactiva (y para evitar el retroceso), pero no esperen que les enamore. Simplemente configure el kwarg 'predeterminado' con 'utcnow' y no se preocupe por' auto_now' o 'auto_now_add', si desea conocer la fecha y hora de TZ. –
Gracias Chris. No creo que funcione "por defecto" al reemplazar "auto_now", ya que este último siempre actualiza el tiempo para cada guardado, mientras que "predeterminado" es solo cuando el campo no tiene valor. – dannyroa