« Rejoignez-nous jeudi à 2 PM, heure de l'Est » est précis pour les seuls participants qui raisonnent déjà en heure de l'Est et relève de la devinette pour tous les autres. Une entreprise de logiciels B2B qui organise régulièrement des webinaires pour un public international a constaté qu'une part notable des absences et des arrivées tardives venait simplement de participants qui se trompaient dans le calcul du fuseau horaire, ou qui ne le faisaient pas du tout et supposaient que l'invitation désignait 2 PM à leur heure locale.
Le formulaire d'inscription de l'entreprise recueillait déjà une adresse e-mail et, pour la planification, une localisation approximative, soit saisie directement, soit déduite de l'adresse IP de la personne au moment de son inscription, résolue via /v1/ip en coordonnées accompagnées du pays et de la ville. Ces coordonnées alimentaient /v1/timezone, qui renvoyait le nom de fuseau horaire IANA correspondant à la localisation de l'inscrit, ce qui donnait à l'entreprise un moyen fiable de calculer l'heure locale correcte du webinaire pour ce participant précis, au lieu de compter sur lui pour faire la conversion.
Dès lors, chaque e-mail de confirmation affichait l'heure du webinaire deux fois : une fois dans le fuseau horaire du présentateur, par souci de cohérence, et une fois calculée spécialement pour le fuseau horaire déterminé du participant, écrite en toutes lettres plutôt que sous forme de décalage obligeant le lecteur à refaire un calcul. Ce double affichage se retrouvait dans l'invitation d'agenda jointe à la confirmation, de sorte qu'un participant ajoutant l'événement à son propre agenda le voyait automatiquement placé à la bonne heure locale, sans devoir se fier à une conversion manuelle.
Comme les webinaires étaient souvent programmés des semaines à l'avance, parfois de part et d'autre d'un changement d'heure dans une région mais pas dans une autre, l'entreprise s'appuyait sur la capacité de la recherche de fuseau horaire à calculer le bon décalage pour la date future précise du webinaire, plutôt que le décalage en vigueur le jour de l'envoi de l'invitation. Stocker le nom IANA plutôt qu'un décalage fixe permettait que cela reste correct sans que personne dans l'entreprise n'ait à surveiller quelles régions allaient changer d'heure ni à ajuster les invitations à la main.
Le résultat mesurable a été une baisse sensible du nombre d'e-mails adressés au support et aux commerciaux pour confirmer l'heure locale réelle d'une session à venir, un coût modeste mais récurrent en temps de travail qui était jusque-là considéré comme inévitable dans l'organisation de webinaires internationaux. La participation s'est aussi légèrement améliorée, même si l'entreprise a pris soin de préciser que cette amélioration venait probablement de plusieurs facteurs, un affichage plus clair du fuseau horaire n'étant qu'un contributeur parmi d'autres et non une explication unique.
Le volume était faible et prévisible, une recherche par inscrit au moment de l'inscription, une charge qui n'a jamais approché le quota gratuit quotidien, même pour une entreprise organisant des webinaires fréquents, car le nombre d'inscriptions à un événement donné atteint rarement une échelle où le coût des requêtes devient un critère significatif.
Donner la bonne heure de réunion à chaque participant, individuellement, plutôt que de demander à chacun de faire sa propre conversion, supprime une source de friction petite mais réelle dans un geste aussi simple que se présenter à un appel programmé. La documentation des deux endpoints se trouve sur /docs/ipv4-lookup/ et /docs/timezone-lookup/.