Chaque appel à /v1/timezone s'appuie sur une table de correspondance qui associe des coordonnées aux limites des fuseaux horaires, et la structure de cette table influe directement sur la rapidité avec laquelle une réponse revient. Nous avons reconstruit cette table de fond en comble, et l'endpoint répond désormais plus vite.
Rien de tout cela ne change l'apparence d'une requête ni le contenu d'une réponse. Envoyez des coordonnées à /v1/timezone et vous obtenez toujours les mêmes champs qu'auparavant : l'identifiant du fuseau horaire, les informations de décalage et le reste de la structure de réponse documentée sur /docs/timezone-lookup/. La seule différence est la rapidité avec laquelle la réponse arrive, ce qui compte surtout pour tout ce qui appelle l'endpoint de façon répétée, comme un lot de coordonnées traitées les unes après les autres ou une fonctionnalité en temps réel qui ne peut pas se permettre de paraître lente.
Les recherches de fuseau horaire se trouvent souvent à des endroits où la vitesse se cumule. Un appel isolé un peu plus rapide passe presque inaperçu, mais une tâche par lots qui détermine les fuseaux horaires de milliers de coordonnées, ou une carte en direct qui affiche l'heure locale pendant qu'un utilisateur déplace un repère, profitent toutes deux directement d'une recherche sous-jacente plus légère. Comme une requête par lots compte chaque coordonnée comme un élément, exactement comme toujours, rien ne change non plus dans la tarification ou le comportement des quotas pour les appels par lots.
Ce travail s'inscrit dans le reste de notre approche de l'endpoint de fuseau horaire : des en-têtes de quota cohérents sur chaque réponse, les mêmes options d'authentification que tous les autres endpoints et la même tarification, qu'il soit appelé directement ou via l'un des dix-sept hôtes compatibles qui manipulent des données de localisation. Une table de correspondance plus rapide ne change rien à tout cela, elle signifie simplement que la réponse arrive plus tôt.
Nous considérons ce genre de reconstruction en profondeur comme de la maintenance ordinaire plutôt que comme une fonctionnalité phare, mais elle mérite d'être mentionnée car l'effet est réel pour quiconque sollicite fortement l'endpoint. Si votre intégration traite des coordonnées en masse, ou si les recherches de fuseau horaire se trouvent sur un parcours où le temps de réponse compte directement pour un utilisateur, vous devriez remarquer la différence sans modifier une seule ligne de code.
La documentation complète de l'endpoint, y compris les paramètres de requête et les champs de réponse, est disponible sur /docs/timezone-lookup/. Rien n'y a changé, à part la rapidité de réponse.