« UTC moins cinq » n'est pas un fuseau horaire, c'est un décalage, et les décalages changent deux fois par an dans la plupart des pays qui appliquent l'heure d'été. C'est exactement pour cette raison qu'une équipe de douze personnes en télétravail programmait des réunions qui tombaient correctement pendant des mois, puis soudain plus du tout, pile autour d'un changement d'heure que personne du côté de la planification n'avait pensé à vérifier.
L'équipe tenait une simple feuille de calcul associant la ville de chaque membre à un décalage fixe par rapport au siège de l'entreprise, mise à jour à la main chaque fois que quelqu'un se souvenait que l'heure d'été approchait. La feuille de calcul était fausse environ six mois par an, de façon tournante, selon les pays qui avaient changé d'heure et ceux qui ne l'avaient pas encore fait, car tous les pays n'appliquent pas l'heure d'été selon le même calendrier, et certains ne l'appliquent pas du tout.
La solution a consisté à remplacer la feuille de calcul par une recherche reflétant les vraies règles des fuseaux horaires plutôt qu'un instantané saisi une fois pour toutes. Pour la ville de chaque membre, l'équipe a déterminé une coordonnée et l'a envoyée à /v1/timezone, qui renvoie le nom de fuseau horaire IANA pour ce point, un nom comme « America/Sao_Paulo » ou « Asia/Kolkata » plutôt qu'un simple décalage. Ce nom porte avec lui les règles réelles d'heure d'été de cette région précise : un outil de planification qui stocke le nom IANA et en calcule le décalage actuel, plutôt que de stocker directement le décalage, reste donc automatiquement correct lors des changements d'heure, puisque les règles se trouvent dans la base de données des fuseaux horaires et non dans une valeur que quelqu'un doit penser à mettre à jour.
L'équipe a intégré cela directement dans son outil de planification des réunions, si bien que proposer un horaire affichait correctement l'heure locale de chaque participant, calculée à l'instant même de la planification plutôt que tirée d'un tableau statique. Pour une réunion proposée plusieurs semaines à l'avance, la capacité de l'endpoint à calculer un décalage pour un moment futur précis comptait aussi, car une réunion planifiée avant le changement d'heure d'une région et tenue après avait besoin du décalage correct postérieur au changement, et non de celui en vigueur le jour de sa planification.
Le changement visible a été moins d'erreurs de planification et moins de messages d'excuse au sujet d'une réunion tombée à une heure déraisonnable pour quelqu'un. Le changement moins visible est que plus personne dans l'équipe n'avait à retenir les calendriers d'heure d'été de quatre pays, ce qui était auparavant la responsabilité informelle et non rémunérée de quelqu'un.
Ce type de solution s'adapte aussi facilement aux petites structures qu'aux grandes. Une équipe de douze personnes et une entreprise de mille personnes ont le même problème de fond, simplement à des volumes différents, et la recherche elle-même ne gagne pas en complexité dans un cas comme dans l'autre, seule sa fréquence d'appel change. Pour une petite équipe, l'utilisation restait largement dans le quota quotidien gratuit inclus avec une clé, puisque déterminer le fuseau horaire d'une douzaine de personnes quelques fois représente une charge minime à côté des 2 500 requêtes gratuites disponibles chaque jour.
Les bugs de fuseau horaire restent généralement invisibles jusqu'à ce qu'ils causent un vrai problème, et à ce moment-là les dégâts se traduisent par une réunion manquée ou un client déconcerté. Corriger une bonne fois la source de données sous-jacente élimine toute cette catégorie d'erreurs pour la suite. La documentation de l'endpoint se trouve sur /docs/timezone-lookup/.