Le problème des clés d'API qui n'expirent jamais
Une clé émise il y a des années, jamais renouvelée et toujours valide aujourd'hui n'est pas une commodité. C'est un risque que personne n'a vraiment examiné depuis des années.
Pourquoi les bugs de fuseau horaire sont généralement un problème de tests, pas de données
Un bug de fuseau horaire n'apparaît presque jamais un mardi ordinaire. Il apparaît la semaine précise d'un changement d'heure, ou dans une région dont le gouvernement vient de modifier ses règles de décalage sans guère de préavis, ou à la limite exacte entre deux fuseaux, là où un cas limite de la correspondance entre coordonnées et fuseau choisit le mauvais côté. Le reste de l'année, un code qui gère mal les fuseaux horaires fonctionne sans aucun problème visible, et c'est exactement ce qui rend ces bugs si tenaces : le mode de défaillance est rare par nature, il est donc rarement détecté avant de se produire réellement en production.
Nous pensons que la plupart de ces bugs sont imputés aux données alors qu'il s'agit en réalité d'une lacune dans les tests. La base de données des fuseaux horaires de l'IANA, qui sous-tend la plupart des traitements sérieux des fuseaux horaires, y compris le nôtre, suit ces changements d'heure et ces modifications de règles au fur et à mesure. Que les données soient disponibles ne signifie pas qu'une application exerce correctement les chemins de code qui ne s'exécutent que pendant la semaine d'un changement d'heure ou qui ne s'appliquent qu'à la poignée de régions aux règles inhabituelles. Si une suite de tests ne simule jamais un passage à l'heure d'été ou d'hiver, ou n'exécute jamais de recherche pour une région avec un décalage non standard d'une demi-heure ou de 45 minutes, l'exactitude des données sous-jacentes ne protégera pas une application d'un bug que seul son propre chemin de code non testé peut éviter.
C'est un cas où la solution est ennuyeuse et précise plutôt qu'enthousiasmante : testez explicitement aux dates du calendrier où les changements d'heure ont lieu, et pas seulement à une date arbitraire choisie par commodité. Testez délibérément quelques régions limites aux décalages inhabituels, et pas uniquement les fuseaux horaires courants aux heures rondes dans lesquels se déroule l'essentiel du développement. Rien de tout cela n'exige de nouvelles données. Cela exige de décider que la semaine rare mérite d'être testée aussi soigneusement que la semaine ordinaire, puisque c'est précisément la semaine rare où le bug apparaîtra pour un vrai utilisateur.
Il existe un piège voisin qui mérite d'être nommé : mettre en cache une seule fois le décalage horaire d'un lieu et réutiliser indéfiniment cette valeur en cache. Un décalage correct en juillet peut être faux en décembre une fois que le changement d'heure l'a modifié, et un cache qui n'en tient pas compte servira avec assurance une réponse périmée sans aucune indication que quelque chose s'est mal passé. Ce n'est pas non plus un problème de qualité des données. C'est un choix d'architecture qui a supposé qu'un fait resterait constant, alors que la nature même de ces données est de ne pas l'être périodiquement.
Nous présentons notre endpoint de fuseau horaire comme l'une des parties du produit qui fonctionnent pleinement, car les données de référence sous-jacentes sont activement maintenues et la logique de recherche est conçue pour tenir compte directement de ces changements plutôt que de supposer un décalage fixe. Le constat plus général dépasse notre propre produit : un bug de fuseau horaire qui atteint un client prouve rarement que les données sources étaient fausses. Il prouve beaucoup plus souvent que personne n'a écrit de test pour la seule semaine de l'année, ou la seule région, où les règles changent réellement.