Was sind die "Standard" -Zeitzonenabkürzungen?

  

Was sind die "Standard" -Zeitzonenabkürzungen?

Dafür gibt es keine Standards. Zeitzonenabkürzungen werden von niemandem offiziell koordiniert. Es gibt einige, die in der IANA TZDB verwendet werden, aber viele davon wurden zufällig ausgewählt. Es gibt oft Diskussionen darüber, welche Abkürzungen verwendet werden sollten. Schauen Sie sich zum Beispiel an, wie viele Beiträge über australische Abkürzungen in den Listenarchiven für April 2013 .

Eine weitere Liste der Zeitzonenabkürzungen finden Sie hier . Wenn Sie genau hinsehen, werden Sie sehen, dass viele nicht eindeutig sind. Zum Beispiel könnte CST "Zentrale Standardzeit" (USA), "China Standardzeit" oder "Cuba Standardzeit" sein. EST könnte "Eastern Standard Time" (USA) oder "Eastern Standard Time" (Australien) sein.

Einige Nicht-Australier bevorzugen vielleicht AEST , aber wer sagt, dass A für Australien und nicht für Amerika sein sollte?

Ein weiteres, sehr häufiges Beispiel: Einige Leute benutzen HAST für Hawaii, während andere HST verwenden, weil ihnen die aleutischen Inseln in Alaska weniger wichtig sind (was A darstellen soll).

Der Punkt ist, dass jede Liste von Zeitzonenabkürzungen, wo immer Sie eine finden, subjektiv und eigensinnig sein wird. Es gibt keinen Standard.

  

Ich speichere Zeitzone nach Offset für eine Anwendung, die dieses Dropdown verwendet:

Bitte tu das nicht . Eine Zeitzone ist nicht ein Offset, und es gibt viel mehr als 24 von ihnen. Bitte lesen Sie das Zeitzonen-Tag-Wiki , insbesondere den Abschnitt "Zeitzone! = Offset".

Aus Ihren Kommentaren:

  

Ich erkenne das jetzt, aber der Rest meiner Anwendungslogik hängt davon schon auf diese Weise ab, und ich muss das heute nur noch vervollständigen, also keine Zeit, es zu ändern.

Dann werden weiterhin viele Fehler in Ihrer Anwendung vorhanden sein. Sie können dies nicht zuverlässig tun - auch nicht, wenn Ihre App nur in den USA läuft. Es spielt keine Rolle, auf welcher Sprache oder Plattform Sie sich befinden. Jede Implementierung, die dies tut, wird viele Konvertierungsfehler haben.

  

Ich bin in Ordnung, diese Arrays hart zu codieren, ich weiß einfach nicht, was die beliebten Zonen außerhalb der USA sind, ich dachte, eine solche Liste wäre schon irgendwo vorhanden.

Wenn es um Zeitzonen geht, sollten Sie nichts fest codieren. Zeitzonenregeln ändern sich ständig, weil sie von Politikern in jedem Land der Welt kontrolliert werden. Es gibt Updates, die mehrmals pro Jahr in der IANA-Zeitzonendatenbank veröffentlicht werden. Auf der PHP-Seite macht die PHP-Dokumentation deutlich, welche Version aktuell verfügbar ist und dass Updates über PECLs Zeitzonedb - welches seine Daten von IANA bezieht.

Was "populär" ist - das ist auch sehr subjektiv. Die Zonen in der TZDB sind alle aus dem einen oder anderen Grund vorhanden. Der einzige Ort, von dem ich weiß, dass er versucht hat, dies zu begrenzen, ist ActiveSupport :: TimeZone von Ruby on Rails. Sie behaupten, eine "sinnvolle Teilmenge von 146 Zonen" zu haben, die Sie in der MAPPING -Konstante auf dieser Seite sehen können. Aber sie sagen nicht, nach welchem ​​Prozess sie entschieden haben, was als sinnvoll erachtet wird, und es gibt klare Versäumnisse. Wenn Sie nicht genau wissen, wo sich jeder einzelne Ihrer Benutzer befindet, würde ich nicht versuchen, zu entscheiden, auf welche Zonen ich mich beschränken soll.

Wenn Ihr Nachher etwas anderes als eine Dropdown-Liste aller 578 Zonen in der TZDB ist, können Sie einen dieser Ansätze ausprobieren:

• Präsentieren zwei Dropdowns. Der erste, der ein Land auswählt. Die Sekunde, um eine Zone innerhalb dieses Landes zu wählen. In PHP können Sie sehen, dass beim Aufruf von DateTimeZone::listIdentifiers ein optionales% co_de akzeptiert wird % -Parameter zum Filtern der Liste.

  Ein gutes Beispiel hierfür sind die Einstellungen für Google Kalender:

  

• Verwenden Sie ein kartenbasiertes Steuerelement, damit der Benutzer seine Zeitzone nach Standort auswählen kann. Es gibt viele davon, aber mein Favorit ist dieser für JavaScript.

  Beispielsweise könnte es so aussehen:

  

Beachten Sie, dass hier die TZDB-Abkürzung von $country angezeigt wird - dies wird nur für eine bequeme Anzeige verwendet. Unter der Haube wählen Sie einen Wert wie EDT .

Schließlich müssen Sie für jeden Benutzer den IANA-Zeitzonenschlüssel speichern, z. B. America/New_York . Sie können keine korrekten Zeitzonenumwandlungen mit einem Wert von America/New_York vornehmen, da Sie nicht alle Regeln dafür haben, wann zu -5 gewechselt wird.

Aktualisieren

Eine Sache, die ich aus Ihrem ursprünglichen Post nicht erkannt habe, aber Sie in Kommentaren geklärt haben, ist, dass Sie damit eine Ziel-Event-Zeitzone auswählen. Ich denke, ich hätte zuerst nach dem Zusammenhang fragen sollen. Ich habe mich dem aus der Perspektive der Auswahl einer einzelnen Zeitzone für Ihren Benutzer und nicht einer bestimmten Zeitzone für ein bestimmtes Ereignis genähert.

Alles, was Sie wirklich benötigen, damit ein Ereignis im richtigen Moment ist, ist der Offset für diesen Moment. Sie könnten also ein Dropdown-Feld verwenden, wie das, das Sie in Ihrer Frage gezeigt haben - aber ich würde keine Zonennamen auslassen. Es wäre buchstäblich eine Liste der Offsets von -4 bis UTC-12:00 . Offenbar haben Sie bereits festgestellt, dass auch ein Versatz von 30 Minuten und 45 Minuten besteht. Sie können Ihre Annahmen hier überprüfen, wenn Sie möchten.

Das allgemeine Problem ist jedoch, dass viele Leute nicht wissen, was der Offset sein soll. Wenn Sie für jeden Zonennamen eine Liste mit dem Offset standard erstellen, könnten Sie den Benutzer dazu verleiten, den falschen Offset auszuwählen. Zum Beispiel könnten sie über ein Datum im Sommer sprechen, das in die US Eastern Daylight Time (-4) fallen sollte, aber sie wählen stattdessen die -5 Auswahl, weil sie "Eastern" sehen. Das Entfernen der Namen hilft also.

Wenn Sie so vorgehen, wie ich es ursprünglich vorgeschlagen hatte, und sie eine aktuelle IANA-Zeitzone auswählen lassen, wird das für viele Szenarien viel besser funktionieren. Es gibt jedoch immer noch ein Szenario, über das Sie nachdenken sollten - wie mehrdeutige und ungültige -Zeiten behandelt werden. Diese treten während der DST-Übergänge auf.

Zum Beispiel könnte ich UTC+14:00 wählen und am 3. November 2013 eine Zeit von 1:00 morgens wählen. Es gibt zwei verschiedene Fälle davon wegen des Fallback-Übergangs (einer im EDT bei -4 und ein anderer in EST bei -5). Ihre App müsste dies überprüfen und den Benutzer fragen, welche der beiden gemeint ist. Ebenso, wenn ich am 10. März 2013 um 2:00 Uhr morgens eintrage, sollte mir deine App mitteilen, dass diese Zeit in dieser Zone nicht existiert (aufgrund des Spring-Forward-Übergangs).

Wenn Sie die Ereigniszeiten tatsächlich speichern möchten, stellen Sie sicher, dass Sie entweder die Kombination aus Datum und Uhrzeit-Offset speichern oder den Offset anwenden, um eine Datums- und Uhrzeitangabe in UTC zu erhalten. Sie wollen nicht, dass es irgendeine Frage darüber gibt, welcher tatsächliche Zeitpunkt durch das Ereignis repräsentiert wird.