Un agent de support qui, dans un bureau, consulte un ticket envoyé à « 3:47 AM » n'a aucune idée s'il était tard pour le client ou s'il était en pleine journée de travail. Des horodatages sans fuseau horaire sont presque inutiles lorsque les clients d'une entreprise sont répartis sur plusieurs continents, et un éditeur de logiciels disposant de services de support dans trois régions s'y heurtait sans cesse. Les agents ouvraient les tickets, vérifiaient le pays de facturation du client, puis cherchaient manuellement si ce pays était en avance ou en retard, et se trompaient assez souvent pour que « désolé de vous déranger si tôt » devienne une plaisanterie récurrente au bureau.
L'entreprise a remplacé les suppositions par deux appels effectués à l'arrivée de chaque ticket. D'abord, /v1/ip lit l'adresse IP du visiteur et renvoie le pays, la région, la ville et les coordonnées, avec un champ de fuseau horaire directement dans la même réponse. Pour la plupart des tickets, ce champ suffisait à lui seul. Pour les cas moins nombreux où davantage de précision importait, comme la planification d'un rappel, les coordonnées issues de cette recherche étaient transmises à /v1/timezone, qui renvoie le nom de fuseau horaire IANA et le décalage UTC actuel pour ce point exact, calculé si besoin pour un moment précis plutôt que pour maintenant.
Le nom IANA compte davantage qu'on pourrait le croire. Un décalage UTC brut change selon des règles d'heure d'été qui diffèrent d'un pays à l'autre et parfois d'une région à l'autre au sein d'un même pays, si bien qu'enregistrer « UTC+2 » dans la fiche d'un client devient discrètement faux deux fois par an. Enregistrer plutôt « Europe/Warsaw » garantit que le décalage est toujours calculé correctement pour la date à laquelle un ticket ou un rappel est prévu, car la base de données des fuseaux horaires qui le pilote suit ces changements de règles au fur et à mesure.
Le changement visible a été une petite ligne en haut de chaque ticket : l'heure locale actuelle du client, à côté de son nom. Les agents ont cessé de demander « est-il tard chez vous » et ont commencé leurs messages par un « bon après-midi » exact. Le routage des tickets s'est aussi amélioré, dès lors que la file pouvait trier les clients selon qu'ils se trouvaient actuellement dans les heures ouvrées de leur propre région, plutôt que selon le service de support qui se trouvait avoir du personnel disponible.
Rien de tout cela n'a nécessité une base de correspondances pays-fuseau horaire tenue à la main, l'approche bricolée que l'entreprise utilisait auparavant et qui échouait chaque fois que l'IP d'un client correspondait à un grand pays s'étendant sur plusieurs fuseaux. Lire le fuseau horaire directement à partir des coordonnées a supprimé toute cette catégorie d'erreurs.
Le volume était faible, une recherche par nouveau ticket, bien en deçà des 2 500 requêtes gratuites par jour incluses avec la clé de l'entreprise. L'outil de support à lui seul n'a jamais été près d'avoir besoin de crédit prépayé, même si la même clé couvrait d'autres parties du produit qui en utilisaient.
La gestion des fuseaux horaires fait partie de ces détails que les clients ne remarquent que lorsqu'ils sont faux. Bien la faire, discrètement, en arrière-plan de chaque ticket, est une petite correction à l'effet démesuré sur l'image que renvoie une équipe support. La documentation des deux endpoints se trouve sur /docs/ipv4-lookup/ et /docs/timezone-lookup/.