tutorial - Resultados inesperados convirtiendo zonas horarias en python

the django project

Question

Estoy tratando de entender por qué obtengo estos resultados al convertir las zonas horarias a UTC:

In [74]: d1 = datetime(2007, 12, 5, 6, 30,tzinfo=pytz.timezone(''US/Pacific''))
In [75]: d1
Out[75]: datetime.datetime(2007, 12, 5, 6, 30, tzinfo=<DstTzInfo ''US/Pacific'' LMT-1 day, **16:07:00 STD**>)
In [76]: d1.astimezone(pytz.utc)
Out[76]: datetime.datetime(2007, 12, 5, 14, 23, tzinfo=<UTC>)

¿Por qué las 6:30 am se convirtieron en 2:23 pm?

Por otro lado, si utilizo el siguiente enfoque, obtengo el resultado esperado:

In [90]: d2 = datetime(2007, 12, 5, 6, 30)
In [91]: uspac = pytz.timezone(''US/Pacific'')
In [92]: d2_aware = uspac.localize(d2)
In [94]: d2_aware.astimezone(pytz.utc)
Out[94]: datetime.datetime(2007, 12, 5, 14, 30, tzinfo=<UTC>)

Answer 1

De la documentación parcial: http://pytz.sourceforge.net/#localized-times-and-date-arithmetic

Desafortunadamente, el uso del argumento tzinfo de los constructores de fecha y hora estándar '''' no funciona '''' con pytz para muchas zonas horarias. [...] Sin embargo, es seguro para las zonas horarias sin transiciones de horario de verano, como UTC. [...] La forma preferida de lidiar con los tiempos es trabajar siempre en UTC, convirtiéndose a la hora local solo cuando se genera una salida para que la lean los humanos.

Answer 2

Estoy revisando algunas preguntas sobre fecha y hora para ver si algunas de las bibliotecas más nuevas resultan más útiles en situaciones como esta (o no). pendulum es uno que almacena la zona horaria con fecha y hora, por lo que es particularmente valioso en situaciones como esta.

>>> import pendulum
>>> d1 = pendulum.datetime(2007,12,5,6,30, tzinfo=''US/Pacific'')
>>> d1
<Pendulum [2007-12-05T06:30:00-08:00]>
>>> d1.timezone
<Timezone [US/Pacific]>
>>> d1.astimezone(tz=''UTC'')
<Pendulum [2007-12-05T14:30:00+00:00]>

Un montón de otras características dulces también.

Answer 3

Imprima d2_aware antes de .astimezone y verá PST-1 (hora estándar del Pacífico), pero en el primer ejemplo tiene LMT-1 (hora media local), y probablemente le puede dar una diferencia de 7 minutos.

Pero no sé por qué pytz usa diferentes zonas horarias.

Answer 4

Lo que obtuve es solo una solución alternativa, la regla simple es Nunca crear datetime con información de zona horaria usando datetime () .

Esta muestra le daría una pista para esto. Como puede ver, puede evitar la diferencia inesperada, solo una vez y solo puede hacer datetime "ingenuo" (es decir, datetime sin información de zona horaria) y luego localizarlo (no se aplica cuando crea datetime en UTC):

import pytz
from datetime import datetime

# make Jan 1 on PDT -> UTC
pdt = pytz.timezone("America/Los_Angeles")
pdtnow1 = datetime(2014,1,1, tzinfo=pdt)
pdtnow2 = pdt.localize(datetime(2014,1,1))
pytz.utc.normalize(pdtnow1)
# > datetime.datetime(2014, 1, 1, 7, 53, tzinfo=<UTC>)
pytz.utc.normalize(pdtnow2)
# > datetime.datetime(2014, 1, 1, 8, 0, tzinfo=<UTC>)

# make Jan 1 on UTC -> PDT
utcnow1 = datetime(2014,1,1, tzinfo=pytz.utc)
utcnow2 = pytz.utc.localize(datetime(2014,1,1))
pdt.normalize(utcnow1)
# > datetime.datetime(2013, 12, 31, 16, 0, 
# > tzinfo=<DstTzInfo ''America/Los_Angeles'' PST-1 day, 16:00:00 STD>)
pdt.normalize(utcnow2)
# > datetime.datetime(2013, 12, 31, 16, 0, 
# > tzinfo=<DstTzInfo ''America/Los_Angeles'' PST-1 day, 16:00:00 STD>)