now - datetime today() python

pytz localize vs datetime replace

Question

Estoy teniendo algunos problemas extraños con la función .localize () de pytz. Algunas veces no haría ajustes al datetime localizado:

.localize el comportamiento:

>>> tz
<DstTzInfo ''Africa/Abidjan'' LMT-1 day, 23:44:00 STD> 
>>> d
datetime.datetime(2009, 9, 2, 14, 45, 42, 91421)

>>> tz.localize(d)
datetime.datetime(2009, 9, 2, 14, 45, 42, 91421, 
                  tzinfo=<DstTzInfo ''Africa/Abidjan'' GMT0:00:00 STD>)
>>> tz.normalize(tz.localize(d))
datetime.datetime(2009, 9, 2, 14, 45, 42, 91421,
                  tzinfo=<DstTzInfo ''Africa/Abidjan'' GMT0:00:00 STD>)

Como puede ver, el tiempo no se ha modificado como resultado de las operaciones de localización / normalización. Sin embargo, si se usa .replace:

>>> d.replace(tzinfo=tz)
datetime.datetime(2009, 9, 2, 14, 45, 42, 91421, 
                  tzinfo=<DstTzInfo ''Africa/Abidjan'' LMT-1 day, 23:44:00 STD>)
>>> tz.normalize(d.replace(tzinfo=tz))
datetime.datetime(2009, 9, 2, 15, 1, 42, 91421,
                  tzinfo=<DstTzInfo ''Africa/Abidjan'' GMT0:00:00 STD>)

Lo cual parece hacer ajustes en datetime.

La pregunta es: ¿cuál es correcto y por qué el otro está mal?

Answer 1

Esta clase DstTzInfo se usa para las zonas horarias donde la compensación de UTC cambia en ciertos momentos. Por ejemplo (como probablemente sabrá), muchas ubicaciones pasan al "horario de verano" al comienzo del verano y luego vuelven a la "hora estándar" al final del verano. Cada instancia de DstTzInfo solo representa una de estas zonas horarias, pero los métodos "localizar" y "normalizar" lo ayudan a obtener la instancia correcta.

Para Abidjan, solo ha habido una transición (según pytz), y eso fue en 1912:

>>> tz = pytz.timezone(''Africa/Abidjan'')
>>> tz._utc_transition_times
[datetime.datetime(1, 1, 1, 0, 0), datetime.datetime(1912, 1, 1, 0, 16, 8)]

El objeto tz que obtenemos de pytz representa la zona horaria anterior a 1912:

>>> tz
<DstTzInfo ''Africa/Abidjan'' LMT-1 day, 23:44:00 STD>

Ahora mirando sus dos ejemplos, vea que cuando llama a tz.localize (d) NO obtiene esta zona horaria anterior a 1912 agregada a su objeto naive datetime. Supone que el objeto datetime que le da representa la hora local en la zona horaria correcta para esa hora local , que es la zona horaria posterior a 1912.

Sin embargo, en su segundo ejemplo con d.replace (tzinfo = tz), su objeto datetime toma el tiempo en la zona horaria anterior a 1912. Esto probablemente no es lo que querías decir. Luego, cuando llamas a dt.normalize, esto se convierte en la zona horaria que es correcta para ese valor de fecha y hora, es decir, la zona horaria posterior a 1912.

Answer 2

Me doy cuenta de que llegué un poco tarde a esto ... pero esto es lo que encontré que funcionó bien. Trabaja en UTC como Alex dijo:

tz = pytz.timezone(''Africa/Abidjan'')
now = datetime.datetime.utcnow()

Luego para localizar:

tzoffset = tz.utcoffset(now)
mynow = now+tzoffset

Y este método maneja perfectamente el DST

Answer 3

localize es la función correcta que se debe usar para crear objetos con fecha y hora con un valor de fecha y hora fijo inicial. El objeto consciente de fecha y hora resultante tendrá el valor de fecha y hora original. Un patrón de uso muy común en mi opinión, y uno que quizás Pytz puede documentar mejor.

replace(tzinfo = ...) es desafortunadamente nombrado. Es una función que es aleatoria en su comportamiento. Aconsejaría evitar el uso de esta función para establecer zonas horarias a menos que disfrutes del dolor autoinfligido. Ya he sufrido suficiente por usar esta función.

Answer 4

localize solo asume que la fecha inocente en que la pasa es "correcta" (¡excepto por no conocer la zona horaria!) y simplemente establece la zona horaria, sin otros ajustes.

Puede (y es aconsejable ...) trabajar internamente en UTC (en lugar de con fechas de programación ingenuas) y usar replace cuando necesite realizar E / S de las fechas de forma localizada ( normalize horario de verano y demás).