Les logiciels qui calculent des décalages horaires supposent souvent implicitement que la règle actuelle d'un fuseau s'est toujours appliquée, et cette hypothèse fonctionne très bien jusqu'au moment où vous devez interpréter correctement un horodatage antérieur au dernier changement de règle : elle produit alors discrètement une réponse fausse qui paraît tout à fait plausible. C'est une source réellement courante de corruption subtile des données dans les systèmes qui stockent ou traitent des horodatages historiques sur une période significative.
Si cela compte, c'est parce que les règles de fuseau horaire, dates de début et de fin de l'heure d'été, décalages standard, et même le fuseau auquel appartient un lieu, ne sont pas figées pour toujours. Elles changent quand les gouvernements les changent, comme expliqué ailleurs, et un horodatage enregistré il y a des années a besoin de la règle réellement en vigueur à cette date précise, et non de celle en vigueur aujourd'hui, pour calculer l'instant correspondant dans un autre fuseau ou en UTC.
C'est précisément pour cette raison que la base de données de fuseaux horaires IANA conserve l'historique complet des changements de règles pour chaque fuseau nommé, et pas seulement la règle actuelle. Un logiciel correctement construit sur cette base peut répondre à la question « quel était le décalage UTC de ce fuseau à cette date historique précise », qui est une question réellement différente et plus complexe que « quel est le décalage UTC de ce fuseau en ce moment », et c'est justement en confondant les deux que les données d'horodatage historiques deviennent discrètement fausses.
Cela se manifeste de façon concrète et pratique. Un système qui convertit un horodatage de journal historique de l'heure locale vers UTC à des fins d'analyse a besoin de la règle historique correspondant à la date et au fuseau d'origine de ce journal, et non de la règle actuelle, sans quoi la conversion introduit une erreur pouvant aller jusqu'à une heure entière dans un sens ou dans l'autre selon la transition concernée. Un système qui calcule l'âge d'une personne ou la durée d'un contrat sur des dates couvrant un changement de règle historique demande le même soin, même si l'impact y est généralement moindre. Même le fait de réafficher un ancien horodatage à un utilisateur dans son heure locale actuelle exige une conversion selon la bonne règle historique pour le fuseau et la date d'origine, et non selon la règle actuelle.
La recommandation pratique est de toujours effectuer les conversions de fuseau horaire avec un système qui connaît les changements de règles historiques pour le fuseau et la date en question, plutôt qu'avec un système qui ne connaît que la règle actuelle, et d'être particulièrement prudent avec tout processus qui convertit par lots des données historiques sur une période susceptible d'inclure un changement de règle. Notre recherche de fuseau horaire peut être interrogée pour un instant précis, en appliquant les règles réellement en vigueur à cette date, ce qui est exactement le comportement nécessaire pour traiter correctement les données historiques au lieu d'appliquer par défaut la règle d'aujourd'hui à chaque calcul, quelle que soit la date réellement traitée.