2011-09-07 4 views
1

J'ai une application python qui envoie des rappels par e-mail aux utilisateurs dans différents fuseaux horaires. L'heure de début est définie sur une date et une heure données et le rappel peut être défini sur un certain nombre de minutes avant l'heure de début.Pourquoi le décalage pytz est-il incorrect?

Le développeur précédent ne prenait pas en compte le fuseau horaire de l'utilisateur, de sorte que les rappels étaient toujours envoyés en fonction de l'heure du serveur. En utilisant le pytz documentation, j'ai d'abord essayé d'utiliser UTC pour tout, et pendant que cela fonctionnait en développement, les rappels étaient toujours en production. Au début, j'ai supposé que c'était un problème avec NTP sur le serveur, mais ce n'était pas le cas.

Je voulais confirmer que le développement et la production se comportaient en effet différemment, donc je créé un script simple pour tester entre les deux:

server_time = datetime.datetime.utcnow() 
print "Server Time:", server_time 

user_timezone = pytz.timezone('America/Montevideo') 
print "User Timezone:", user_timezone 

user_offset = user_timezone.utcoffset(server_time) 
print "Offset:", user_offset 

user_datetime = server_time + user_offset 
print "User Time:", user_datetime 

Le résultat dans le développement (correct):

Server Time: 2011-09-07 16:53:00.711334 
User Timezone: America/Montevideo 
Offset: -1 day, 21:00:00 
User Time: 2011-09-07 13:53:00.71133 

Le résultat de la production (incorrect):

Server Time: 2011-09-07 16:53:01.767143 
User Timezone: America/Montevideo 
Offset: -1 day, 20:15:00 
User Time: 2011-09-07 13:08:01.767143 

il ressemble pytz donne simplement le mauvais décalage. Notez que cela n'a pas d'importance si j'utilise un fuseau horaire différent; tout ce que j'ai essayé donne le mauvais décalage. En ce qui concerne la différence dans les environnements, les deux sont des boîtes Ubuntu, mais la production tourne sous Python 2.5.2 et le développement est 2.6.2.

Il n'y a pas beaucoup de bugs reported for pytz, et je n'ai pas trouvé de raison pour différents décalages dans mes recherches.

Est-ce un problème avec les données pytz sur mon serveur de production? Un bug de pytz? Ou un problème avec ma compréhension de pytz? Qu'est-ce que je rate?

+0

Utilisez-vous un serveur Debian? Regardez les différences entre/usr/share/zoneinfo/America/Montevideo sur votre serveur de développement et de production –

Répondre

2

En utilisant la version pytz 2010

$ python test.py 
Server Time: 2011-09-16 00:20:49.479426 
User Timezone: America/Montevideo 
**Offset: -1 day, 20:15:00** wrong! 
User Time: 2011-09-15 20:35:49.479426-03:00 

En utilisant la version pytz 2011

$ python test.py 
Server Time: 2011-09-16 00:36:54.764812 
User Timezone: America/Montevideo 
**Offset: -1 day, 21:00:00** great! 
User Time: 2011-09-15 21:36:54.764812 

Regardez le pytz.VERSION et assurez-vous que vous utilisez au moins 2011h

>>> import pytz 
>>> pytz.VERSION 
'2011h' 

Si vous avez 2010, retirez et remplacez:

>>> pytz.__file__ 
/usr/lib/python2.6/dist-packages/pytz/__init__.pyc 

$ sudo rm -r /usr/lib/python2.6/dist-packages/pytz* 
$ sudo pip install pytz == 2011h 
+0

Beau travail. Le décalage est maintenant correct. La version de production était 2009a. Le serveur n'avait pas pip, et bien que easy_install se plaigne du "== 2011h", il a installé le paquet. J'avais essayé de mettre à jour pytz, mais je l'ai fait manuellement plutôt que d'utiliser easy_install. Évidemment, la dernière version de pytz ne fonctionne pas avec python 2.5, et je n'ai pas réalisé que tout ce que j'avais à faire pour mettre à jour était effacer l'ancienne version et laisser easy_install fournir le dernier paquet disponible pour ma version python. Encore une fois, beau travail. Merci! Maintenant, retour à l'intégration ... – bogeymin

Questions connexes