Deux fois par an, dans les fuseaux qui appliquent l'heure d'été, il arrive à l'horloge quelque chose d'étrange dont la plupart des logiciels ne tiennent jamais compte. Lorsque l'on avance les horloges, une heure de temps local n'existe tout simplement pas, si bien qu'un horodatage comme « 2:30 h » à cette date ne s'est jamais produit. Lorsque l'on recule les horloges, une heure se produit deux fois : « 1:30 h » a eu lieu une fois avant le changement et une fois après, et un horodatage local seul, sans autre information, ne permet pas de savoir de laquelle il s'agit.
Ce n'est pas un cas limite rare qui ne concernerait que des usages exotiques. C'est un événement calendaire ordinaire qui revient chaque année dans chaque fuseau appliquant l'heure d'été, et il fait silencieusement échouer tout code qui considère l'heure locale comme toujours bien définie. Un système de planification qui enregistre « réserver pour 1:45 h » sans enregistrer aussi le décalage UTC au moment de la réservation ne peut pas savoir, des mois plus tard, lequel des deux « 1:45 h » était visé si la réservation tombe la nuit du changement d'heure.
La pratique la plus sûre consiste à stocker les horodatages en UTC partout en interne et à ne les convertir en heure locale que pour l'affichage. L'UTC n'a ni heure d'été ni ambiguïté : une fois un instant enregistré ainsi, il reste correct quoi qu'il advienne ensuite des règles horaires locales. Ne convertissez dans le fuseau horaire local de l'utilisateur qu'au moment de le lui afficher, en utilisant les règles en vigueur pour ce fuseau à cet instant précis. C'est exactement pour cela qu'il vaut la peine d'utiliser une recherche de fuseau horaire qui accepte un instant précis, et pas seulement un lieu, plutôt que de mettre un décalage en cache une fois pour le réutiliser.
Si vous construisez quoi que ce soit qui planifie ou journalise des événements, voici des cas limites à tester explicitement : une réservation faite pour l'heure inexistante lors du passage à l'heure d'été, un horodatage situé dans l'heure répétée lors du passage à l'heure d'hiver, et un événement planifié dont la date franchit un changement d'heure entre sa création et sa survenue. Aucun de ces cas n'est hypothétique. Ils se produisent selon un calendrier fixe et prévisible chaque année, et les tester une fois pendant le développement coûte bien moins cher que de déboguer un ticket d'assistance au sujet d'une réunion qui semble s'être décalée d'une heure.
Si votre système a besoin du décalage correct pour un instant précis plutôt que du seul nom de fuseau, demandez-le directement au lieu de le déduire d'une valeur en cache. La recherche de fuseau horaire de My Geocode accepte un instant précis et applique les règles d'heure d'été pour cette date exacte : le décalage renvoyé est donc correct même juste à la limite d'un changement d'heure.