Que dois-je faire dans un environnement de support avant le lancement de Daylight Savings?

Question

Mon entreprise soutient les applications suivantes pour un client américain:

IBM Mainframe , DB2 , Unix, Teradata , Oracle , SQL Server 2005 , Lawson

Depuis l'heure avancée commencera par le mois prochain, je voudrais connaître vos pensées générales sur ce que nous devrions faire attention afin que nous puissions éviter de mauvais incidents?

Merci, Visakh

Answer 1

d'été peut être un peu délicat, quelques réflexions:

• Le jour d'été doit soit 23 ou 25 heures, pas 24 comme d'habitude
• Il y a soit un écart entre 02h00 et 03h00 ou ces heures apparaissent deux fois

Vous devez toujours utiliser les fuseaux horaires lorsque vous obtenez des données de l'extérieur, sinon, vous aurez des problèmes. Par exemple. vous ne pouvez pas savoir si l'expéditeur a déjà modifié son paramètre d'heure d'été ou non car vous ne pouvez pas savoir avec certitude si tout fonctionne correctement sur l'appareil et en outre, la plupart des utilisateurs ne modifient pas le fuseau horaire, ils changent le temps lui-même et cela vous mènera à de sérieux ennuis. Les téléphones portables ne modifient parfois pas le réglage de la lumière du jour, les utilisateurs changent simplement le temps de 02h00 à 03h00 CET! C'est évidemment faux car le temps lui-même ne change pas, c'est le fuseau horaire! Il est encore 02:00 CET mais 03:00 CEST.

Vous devriez probablement vérifier les produits/bibliothèques que vous utilisez s'ils fonctionnent correctement avec les changements de fuseau horaire.

J'ai testé notre python (avec mx.DateTime) environnement, si elle sait correctement le fuseau horaire à utiliser:

programme de test:

from mx.DateTime import * 

def f(dt): 
    return dt.Format("%Y-%m-%d %H:%M %Z") 

base = ISO.ParseDateTime('2009-03-29 00:00') 

for i in range(10): 
    test = base + i*(30*oneMinute) 
    diff = test.ticks()-base.ticks() 

    print "Seconds between %s and %s: %d(%d) diff=%d" % (f(base), 
                 f(test), diff, 
                i*1800, i*1800-diff) 

sortie pour moi (vivant en Allemagne 29 Mars est le jour d'été):

$ python test.py 
Seconds between 2009-03-29 00:00 CET and 2009-03-29 00:00 CET: 0(0) diff=0 
Seconds between 2009-03-29 00:00 CET and 2009-03-29 00:30 CET: 1800(1800) diff=0 
Seconds between 2009-03-29 00:00 CET and 2009-03-29 01:00 CET: 3600(3600) diff=0 
Seconds between 2009-03-29 00:00 CET and 2009-03-29 01:30 CET: 5400(5400) diff=0 
Seconds between 2009-03-29 00:00 CET and 2009-03-29 02:00 CEST: 7200(7200) diff=0 
Seconds between 2009-03-29 00:00 CET and 2009-03-29 02:30 CEST: 9000(9000) diff=0 
Seconds between 2009-03-29 00:00 CET and 2009-03-29 03:00 CEST: 7200(10800) diff=3600 
Seconds between 2009-03-29 00:00 CET and 2009-03-29 03:30 CEST: 9000(12600) diff=3600 
Seconds between 2009-03-29 00:00 CET and 2009-03-29 04:00 CEST: 10800(14400) diff=3600 
Seconds between 2009-03-29 00:00 CET and 2009-03-29 04:30 CEST: 12600(16200) diff=3600 

Comme vous pouvez le voir avec mx.DateTime qui fonctionne correctement, mais il y a beaucoup de bibliothèques et de produits où cela ne fonctionne pas.