Die Nutzung Ihres Schlüssels überwachen, bevor Sie an ein Limit stoßen
Wenn Sie Ihre Kontingent-Header laufend beobachten, wissen Sie, wann ein Limit näher rückt, lange bevor eine Anfrage tatsächlich abgelehnt wird.
Ein Zeitstempel, der in der Zeitzone Ihres Servers angezeigt wird, ist für fast niemanden korrekt, außer für diejenigen, die zufällig in derselben Zone sitzen, und das ist bei einer Website mit Besuchern aus aller Welt nahezu niemand.
Eine IP-Abfrage liefert direkt ein Zeitzonenfeld und damit die Kennung, die Sie brauchen, um jeden Zeitstempel auf der Seite zu lokalisieren.
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"
}Speichern Sie jeden Zeitstempel in Ihrer Datenbank wie gewohnt in UTC und rechnen Sie erst bei der Anzeige in die lokale Zone des Besuchers um, auf dem Server, mithilfe der ermittelten Zeitzonenkennung. Da diese Website alles serverseitig ohne clientseitiges JavaScript rendert, erfolgen Umrechnung und Formatierung, bevor die Seite gesendet wird, und nicht erst danach im Browser.
local_time = convert_to_timezone(stored_utc_timestamp, "America/Sao_Paulo")Eine Bestellbestätigungsseite mit den Zeitpunkten „bestellt am“ und „erwartet bis“ ist ein gutes Beispiel dafür, wo das über eine einfache Uhr im Seitenkopf hinaus wichtig ist. Wenn Sie beide Zeitstempel über dieselbe Besucherzone umrechnen, statt versehentlich einen in Serverzeit zu lassen, bleiben die beiden Angaben konsistent, und Sie vermeiden die verwirrende Situation, dass die erwartete Lieferzeit früher zu liegen scheint als die Bestellzeit, weil nur eine davon umgerechnet wurde.
Zeitzone und Format hängen zusammen, sind aber getrennte Entscheidungen. Ein Besucher in einer Zone, in der üblicherweise die 24-Stunden-Uhr und die Datumsreihenfolge Tag-Monat-Jahr verwendet werden, profitiert von einer passenden Formatierung und nicht nur von einem verschobenen Stundenwert in einem Format, das weiterhin fremd wirkt. Kombinieren Sie den country_code aus derselben IP-Abfrage mit einer kleinen Formatierungstabelle, wenn Sie über die reine Anpassung der Stunde hinausgehen möchten.
Implementieren Sie die Umrechnung nicht als festen Stundenversatz, der einmal berechnet und danach auf jeden Zeitstempel angewendet wird. Der tatsächliche Versatz einer Zone gegenüber UTC kann sich im Laufe des Jahres durch die Sommerzeit ändern, sodass ein in einer Jahreszeit korrekt umgerechneter Zeitstempel in einer anderen um eine Stunde falsch sein kann, wenn der Code eine gespeicherte Versatzzahl anwendet, statt über die Zeitzonenkennung selbst mit einer ordentlichen Datums- und Zeitbibliothek umzurechnen.
Nicht jede Zeitzone liegt um ganze Stunden versetzt zu UTC. Manche sind um 30 oder 45 Minuten statt um eine volle Stunde versetzt. Wenn Sie sich auf eine Datumsbibliothek verlassen, die die vollständige IANA-Zeitzonenkennung versteht, statt auf einen vereinfachten, rein stundenbasierten Versatzwert, wird das korrekt behandelt, ohne dass Sie Sonderfallcode schreiben müssen. Die Felder utc_offset und abbreviation aus der Dokumentation zur Zeitzonenabfrage sind nützlich, wenn Sie den Versatz ausdrücklich neben einer umgerechneten Zeit anzeigen möchten.
Ermitteln Sie die Zeitzone einmal pro Besuchersitzung und verwenden Sie sie für jeden Zeitstempel auf jeder Seite während dieses Besuchs wieder, statt die API für jedes einzelne angezeigte Datum erneut aufzurufen, da sich die Zone selbst während einer Sitzung nicht ändert.
Eine Abfrage pro neuer Sitzung deckt die Lokalisierung jedes während dieses Besuchs angezeigten Zeitstempels ab, eine Anfrage, egal wie viele Daten auf der Seite erscheinen. So bleibt selbst eine inhaltsreiche Website deutlich innerhalb der 2.500 kostenlosen Anfragen pro Tag, die in jedem Schlüssel enthalten sind.
Lokale Zeit- und Datumsformate auf einer ganzen Website richtig darzustellen, läuft auf eine Abfrage pro Sitzung und danach konsistentes serverseitiges Rendering hinaus. Die Dokumentation zur IPv4-Abfrage und die Dokumentation zur Zeitzonenabfrage behandeln beide Wege, die Zone zu ermitteln.