2008-10-26 7 views
1

Certains tests unitaires ont commencé à échouer aujourd'hui après un changement d'heure d'été.Changement de l'heure d'été affectant le résultat de l'enregistrement et du chargement d'un fichier icalendar?

Nous utilisons le iCalendar python module pour charger et enregistrer des fichiers ics.

Le script suivant est une version simplifiée de notre test. Le script fonctionne bien en 'été' et échoue en 'hiver', dès ce matin. La panne peut être reproduite en réglant l'horloge manuellement. Voici la sortie du script:

[[email protected] icalendar]# date 10250855 
Sat Oct 25 08:55:00 CEST 2008 
[[email protected] icalendar]# python dst.py 
DTSTART should represent datetime.datetime(2015, 4, 4, 8, 0, tzinfo=tzfile('/usr/share/zoneinfo/Europe/Brussels')) Brussels time 
DTSTART should represent datetime.datetime(2015, 4, 4, 6, 0, tzinfo=<icalendar.prop.UTC object at 0x956b5cc>) UTC 
DTSTART represents datetime.datetime(2015, 4, 4, 6, 0, tzinfo=<icalendar.prop.UTC object at 0x956b5cc>) Brussels time 
[[email protected] icalendar]# date 10260855 
Sun Oct 26 08:55:00 CET 2008 
[[email protected] icalendar]# python dst.py 
DTSTART should represent datetime.datetime(2015, 4, 4, 8, 0, tzinfo=tzfile('/usr/share/zoneinfo/Europe/Brussels')) Brussels time 
DTSTART should represent datetime.datetime(2015, 4, 4, 6, 0, tzinfo=<icalendar.prop.UTC object at 0x96615cc>) UTC 
DTSTART represents datetime.datetime(2015, 4, 4, 7, 0, tzinfo=<icalendar.prop.UTC object at 0x96615cc>) Brussels time 
Traceback (most recent call last): 
    File "dst.py", line 58, in <module> 
    start.dt, startUTCExpected) 
AssertionError: calendar's datetime.datetime(2015, 4, 4, 7, 0, tzinfo=<icalendar.prop.UTC object at 0x96615cc>) != expected datetime.datetime(2015, 4, 4, 6, 0, tzinfo=<icalendar.prop.UTC object at 0x96615cc>) 

Et voici le whole script. Donc, des questions: - pourquoi mon heure actuelle (et quelle partie de DST je suis dans) affecte le chargement/enregistrement/analyse des timestamps? Je m'y attendrais pas. - Comment testeriez-vous ce type de bug, s'il s'agit d'un bug? Évidemment, je ne veux pas que mes tests unitaires réinitialisent l'horloge de mon ordinateur.

+0

J'ai connu ce genre de problème avec Unit Test et Timezone/TZ + DST en près de 8 ans. Je suis vraiment curieux de la réponse à cette question dans un terme plus générique (Comment se préparer à un test d'unité solide sur les changements DST) – Jonke

+0

Le lien vers l'ensemble de votre script ne fonctionne pas. – Jonke

Répondre

1

Sans regarder votre code (et le script d'exécution de test cité que mon cerveau ne comprend pas maintenant) Je remarque que vous essayez d'obtenir une heure qui est dans un fuseau horaire différent de celui où vous vous trouvez. (Pensez à DST comme un autre TIMEZONE au lieu de + -1 heure du fuseau horaire actuel). Cela pourrait (selon la façon dont vous le faites) conduire à un gain ou une perte d'heures. (Comme lorsque vous volez, vous commencez en même temps et vous arrivez à votre position avant de commencer, tout en heure locale)

Questions connexes