Surveillez l'utilisation de votre clé avant d'atteindre une limite
Surveiller vos en-têtes de quota au fil de l'eau vous indique quand une limite approche, bien avant qu'une requête ne soit effectivement refusée.
Adapter les formats de date et d'heure au fuseau horaire du visiteur
Un horodatage affiché dans le fuseau horaire de votre serveur ne se lit correctement que pour les personnes qui se trouvent dans ce même fuseau, ce qui, pour un site dont les visiteurs viennent de partout, ne représente presque personne.
Obtenir le fuseau du visiteur
Une recherche d'IP renvoie directement un champ timezone, qui vous donne l'identifiant nécessaire pour localiser n'importe quel horodatage de la page.
GET /v1/ip?ip=203.0.113.77{
"status": "ok",
"ip": "203.0.113.77",
"version": 4,
"found": true,
"country": "Brazil",
"country_code": "BR",
"region": "Rio de Janeiro",
"city": "Rio de Janeiro",
"postcode": "20040",
"lat": -22.9068,
"lon": -43.1729,
"timezone": "America/Sao_Paulo",
"asn": 5566,
"org": "Example ISP"
}Convertir les horodatages stockés
Stockez chaque horodatage de votre base de données en UTC, comme d'habitude, et convertissez-le dans le fuseau local du visiteur uniquement au moment de l'affichage, sur le serveur, à l'aide de l'identifiant de fuseau horaire que vous avez obtenu. Comme ce site rend tout côté serveur sans JavaScript côté client, la conversion et le formatage ont lieu avant l'envoi de la page, et non après, dans le navigateur.
local_time = convert_to_timezone(stored_utc_timestamp, "America/Sao_Paulo")Un second exemple : l'horodatage d'une confirmation de commande
Une page de confirmation de commande affichant les heures « passée à » et « prévue pour » est un bon exemple de cas où cela compte au-delà d'une simple horloge en en-tête de page. Convertir les deux horodatages avec le même fuseau du visiteur, plutôt que d'en laisser un par inadvertance à l'heure du serveur, garde les deux valeurs cohérentes et évite une situation déroutante où l'heure de livraison prévue semble antérieure à l'heure de la commande parce que l'une a été convertie et l'autre non.
Formater, et pas seulement convertir
Le fuseau horaire et le format sont des choix liés mais distincts. Un visiteur situé dans une zone où l'on utilise couramment le format 24 heures et l'ordre jour-mois-année pour les dates bénéficie d'un formatage adapté, et pas seulement d'une heure décalée écrite dans un format qui lui semble toujours étranger. Associez le country_code issu de la même recherche d'IP à une petite table de formats si vous voulez aller au-delà du simple ajustement de l'heure.
Une erreur courante à éviter
N'implémentez pas la conversion sous forme de décalage horaire fixe, calculé une fois puis appliqué à tous les horodatages suivants. Le décalage réel d'un fuseau par rapport à UTC peut changer au cours de l'année avec l'heure d'été : un horodatage converti correctement à une saison peut donc être faux d'une heure à une autre si le code applique un nombre de décalage stocké au lieu de convertir via l'identifiant de fuseau horaire lui-même, avec une véritable bibliothèque de dates et d'heures.
Un cas limite : les décalages qui ne sont pas des heures entières
Tous les fuseaux horaires ne sont pas décalés d'un nombre entier d'heures par rapport à UTC. Certains le sont de 30 ou 45 minutes plutôt que d'une heure pleine. S'appuyer sur une bibliothèque de dates qui comprend l'identifiant de fuseau horaire IANA complet, plutôt qu'une valeur de décalage simplifiée limitée aux heures, gère correctement ce cas sans aucun code spécifique de votre part. Les champs utc_offset et abbreviation décrits dans la documentation de la recherche de fuseau horaire sont utiles si vous voulez afficher explicitement le décalage à côté d'une heure convertie.
Mettre le fuseau en cache pour la session
Recherchez le fuseau horaire une fois par session de visiteur et réutilisez-le pour chaque horodatage affiché sur chaque page pendant cette visite, plutôt que d'appeler à nouveau l'API pour chaque date affichée, puisque le fuseau lui-même ne change pas en cours de session.
Coût de la localisation d'un site entier
Une recherche par nouvelle session couvre la localisation de chaque horodatage affiché pendant cette visite : une seule requête, quel que soit le nombre de dates présentes sur la page. Même un site riche en contenu reste ainsi largement dans les 2 500 requêtes gratuites par jour incluses avec chaque clé.
Bien gérer l'heure locale et le format des dates sur tout un site se résume à une recherche par session, suivie d'un rendu cohérent côté serveur. La documentation de la recherche IPv4 et la documentation de la recherche de fuseau horaire couvrent les deux façons d'obtenir le fuseau.