2012-10-09 20 views
5

Duplicar posibles:
Weird timezone issue with pytzPYTZ 'América/Edmonton' compensado mal

Esto parece mal:

>>> import pytz 
>>> z1 = timezone('America/Edmonton') 
>>> z2 = timezone('US/Mountain') 
>>> z1 
<DstTzInfo 'America/Edmonton' LMT-1 day, 16:26:00 STD> 
>>> z2 
<DstTzInfo 'US/Mountain' MST-1 day, 17:00:00 STD> 
>>> pytz.VERSION 
'2012f' 
>>> 

'América/Edmonton' y 'Estados Unidos/Oriente 'debe ser el mismo huso horario (17:00:00 STD). Sin mencionar 16:26:00 no tiene ningún sentido.

- Actualización -

Lo anterior tiene sentido en el contexto de la respuesta de Jon Skeet. Sin embargo, las cosas se ponen raras cuando hago esto:

>>> d = datetime.now() 
>>> d 
datetime.datetime(2012, 10, 9, 15, 21, 41, 644706) 

Creé una fecha ingenua. Desde 'América/Edmonton' es mi zona horaria, trato de establecer manualmente que:

>>> d2 = d.replace(tzinfo=timezone('America/Edmonton')) 
>>> d2 
datetime.datetime(2012, 10, 9, 15, 21, 41, 644706, tzinfo=<DstTzInfo 'America/Edmonton' LMT-1 day, 16:26:00 STD>) 

Esto no debería haber cambiar nada porque esa es la correcta TZ. Sin embargo:

>>> d2.astimezone(timezone('US/Eastern')) 
datetime.datetime(2012, 10, 9, 18, 55, 41, 644706, tzinfo=<DstTzInfo 'US/Eastern' EDT-1 day, 20:00:00 DST>) 

Esto debería dame un desplazamiento de 2 horas (diferencia entre 'nosotros/Oriental' y 'América/Edmonton') pero me da 3 horas 26 minutos (que es de 2 horas más uno hora 26 minutos: D)

insertando timezone('US/Mountain') produce el resultado correcto en astimezone(). Crear un datetime con "America/Edmonton" también funcionará correctamente.

+0

lo que sucede cuando se construye el 'datetime' con la zona horaria actual para empezar, en lugar de utilizar' replace'? (Parece que esto está básicamente roto ...) –

+0

Entonces funciona bien. Lamentablemente, esa no es una opción en mi caso, ya que el datetime ingenuo es devuelto por otra función que no tengo control :( – Goro

Respuesta

9

El documentation for pytz dice explícitamente que crear una fecha y hora directamente desde una zona horaria no funcionará todos los casos, y dirige a hacer lo siguiente en su lugar:

d2 = timezone('America/Edmonton').localize(d) 
+1

ah, por supuesto. RTFM :) – Goro

3

cuanto a los datos 2012c TZDB, aquí está el conjunto de reglas para América/Edmonton:

Zone America/Edmonton -7:33:52 -  LMT 1906 Sep 
         -7:00 Edm  M%sT 1987 
         -7:00 Canada M%sT 

No me queda claro qué fecha/hora de la salida de Python está tratando de lograr que los/nombre de desplazamiento para, pero I sospechoso es algo así como 1900 - en cuyo caso el 16:26:00 tiene algún sentido con el desplazamiento de -7: 33: 52, y también coincidiría con la abreviatura.

Por lo tanto, es totalmente factible que los datos de zona horaria estén bien, y es solo elegir mostrar una fecha/hora impar como ejemplo. (No tiene sentido para mí que la salida de una zona horaria muestre un tiempo, para ser honesto ...)

+2

Hasta que intente adjuntar el huso horario a una fecha/hora, muestra la definición más antigua que contiene –

+0

@MarkRansom: Eso sin duda lo explicaría, sí ... –

+0

ah, eso tiene sentido entonces.Sin embargo, todavía estoy viendo cosas extrañas cuando trato de usar astimezone() - elaborado anteriormente – Goro