Was ist die richtige Zeitzone, um Zeiten für Ereignisse online anzuzeigen?

Auf meiner Website finden regelmäßig vom Benutzer geplante Veranstaltungen statt. Derzeit verwenden wir unsere Zeitzone EDT (oder EST) als Basiszeitzone für alle Ereignisse auf der Website. Ich denke, das ist entweder 1) falsch oder 2) sehr verwirrend. Derzeit haben wir Benutzer in den USA und in Europa.

Ist die richtige Methode zum Lokalisieren von Zeiten basierend auf der Zeitzone des Kunden? UTC / GMT verwenden?

Vielen Dank

Ehrlich gesagt ist dies ein Problem, das häufig auftritt, wenn eine Website von mehreren Zeitzonen verwendet wird. Es gibt eine lange Liste von Möglichkeiten, um den Kampf zu überwinden. Um Badp zusammenzufassen, es gibt viele Faktoren, die dazu beitragen, wie verschiedene Zeitzonen verarbeitet werden.

Die meisten Websites entscheiden sich für eine von zwei verschiedenen Lösungen, um dieses Problem zu lösen:

1) Speichern Sie alles, was ein Datum als UTC enthält, in der Datenbank ... und lassen Sie eine benutzerdefinierte Einstellung für Benutzer auf Ihrer Website zu, in welcher Zeitzone sie sich befinden ... oder führen Sie eine Geo-IP-Suchmagie durch, um dies herauszufinden Wo auf der Welt sie sich befinden und die entsprechende Zeitzone finden ... und dann jedes Mal, wenn Sie das Datum anzeigen ... stellen Sie sicher, dass Sie die für die Lokalisierung erforderliche Funktion aufrufen. Nahezu jede Programmiersprache verfügt über eine Methode zum Anzeigen von Datumsangaben in einer bestimmten Zeitzone. Sie müssten dies auch in umgekehrter Reihenfolge tun, wenn Benutzer Daten einfügen. (Nehmen Sie sich die Ortszeit und konvertieren Sie sie für DB-Speicher wieder in UTC.) Dies ist wahrscheinlich der häufigste Ansatz. Dies würde Ihnen auch viel Zeit sparen, wenn Sie versuchen, das Rad neu zu erfinden. Soweit anonyme Besucher gehen ... Sie können entweder A) bei EST / EDT bleiben (indem Sie integrierte Funktionsaufrufe für die Anzeige verwenden) oder B) zur Geo-IP-Lookup-Sache zurückkehren und eine Zeitzone auswählen, die auf einer fundierten Vermutung basiert. Es ist auch eine gute Idee, immer die Zeitzone anzugeben, in der Datum und Uhrzeit angezeigt werden. Sagen Sie also niemals "12:00" ... stellen Sie sicher, dass dort "12:00 EDT" steht.

oder 2) Folgen Sie dem Modell von stackexchange (und vielen anderen), um den Unterschied zwischen jetzt und dem Zeitpunkt der Erstellung des Beitrags anzuzeigen. dh anstelle von "gepostet am x Datum" ... würden Sie "vor x Stunden" oder "vor x Tagen x Stunden" usw. ... oder für zukünftige Daten ... "in 6 Tagen 14 Stunden ..." tun wird in vielen Situationen immer häufiger ... ist aber für Kalenderpläne nicht so ideal.

Natürlich ... Sie können immer noch eine Art Hybrid aus beiden verwenden ... und Sie müssen möglicherweise sogar noch einen Schritt weiter gehen und Daten als utc speichern ... aber auch eine bestimmte Zeitzone für ein Ereignis speichern. Letztendlich liegt die Entscheidung bei Ihnen.

Hier ist das Problem: Die EU und die USA schalten die Sommerzeit nicht gleichzeitig ein und aus. In diesem März gab es einen Unterschied von drei Wochen zwischen diesen Ereignissen.

Folgendes passiert in dieser Zeit. Angenommen, Sie haben jeden Tag zur gleichen Zeit eine Veranstaltung und da Sie in den USA ansässig sind, werden Sie die Zeiten mithilfe der US-Sommerzeit anpassen.

Day (2001)   United States   Europe      United Kingdom   Global    Time delta
March 5th    EST 1500        CET  2100   GMT 2000         GMT 2000        +23h
March 6th    EDT 1500        CET  2000   GMT 1900         GMT 1900        +24h
March 7th    EDT 1500        CET  2000   GMT 1900         GMT 1900        +24h
..............................................................................
March 26th   EDT 1500        CET  2000   GMT 1900         GMT 1900        +24h
March 27th   EDT 1500        CEST 2100   BST 2000         GMT 1900        +24h

Lassen Sie uns alle Möglichkeiten analysieren:

• Wenn Sie die Uhrzeit in einer globalen Zeitzone anzeigen und als UTC bezeichnen , was sich als richtig anfühlt, werden Sie Ihre amerikanischen Kunden verwirren, die unterschiedliche UTC-Zeiten (gestern 20 Uhr, heute 19 Uhr) für die Uhrzeit sehen werden Dieselbe Wanduhrzeit (gestern 15 Uhr, heute wieder 15 Uhr) und dann Ihre Kunden in der EU, die nicht sehen, dass sich die angegebene Uhrzeit ändert, und dennoch ihre Ereigniszeit für die Wanduhr ändern müssen.

• Wenn Sie die Zeit in einer globalen Zeitzone anzeigen und als GMT bezeichnen , verwirren Sie nicht nur US-Kunden, sondern auch Kunden aus Großbritannien, die von GMT zu BST wechseln. Es ist nicht intuitiv zu verstehen, dass EDT 1500 und EST 1400 der gleiche Zeitpunkt sind. Übersetzen Sie das jetzt in BST / GMT (mit dem zusätzlichen Problem, dass Sie in keinem Teil der Site BST-Zeiten anzeigen).

• Wenn Sie die Zeitzone in einer EU-Zeitzone anzeigen (ich habe CET / CEST verwendet , um GMT / UTC-Verwechslungen zu vermeiden), ist dies für Ihre US-Kunden, die die Ereigniszeit zweimal hin und her wechseln sehen und dennoch keine Wand erleben, offensichtlich sehr verwirrend Uhrzeit ändern sich. Während Ihre US-Kunden möglicherweise auf den ersten Wechsel vorbereitet sind (schließlich müssen sie ihre Wanduhren am selben Tag ändern), werden sie von letzterem überrascht sein.

• Wenn Sie die Zeitzone in der US-Zeitzone anzeigen (wie EST / EDT ), wird die genaue Situation oben erläutert, aber gespiegelt!

Dies scheint eine hoffnungslose Situation zu sein! Nach vier Jahren, in denen ich dieses Rigmarole durchlaufen habe (natürlich zweimal im Jahr), habe ich Folgendes angesprochen: "Erstelle eine Zeitzone."

Ich bin genau in der oben abgebildeten Situation, also habe ich "NYT" (New York Timezone) erfunden, damit ich "1500 NYT" schreiben kann, um "15 Uhr in der Zeitzone, die New York gerade verwendet" zu bedeuten.

Dies hat den Vorteil, dass der Benutzer, solange er weiß, dass der DST-Walzer läuft, auf sehr einfache Weise in seine eigene Zeitzone konvertieren kann: Google " Zeit in New York ", um zu sehen, wie spät es in NY ist , dann arbeite es von dort aus. Sie können sogar ausgefallene geolokalisierte Dienste wie time.is/15:00_in_New_York nutzen .

Beachten Sie, dass Sie zwar Zeitzonenabkürzungsnamen in time.is verwenden können, ich Sie jedoch dringend auffordere, dies nicht zu tun, da sie selbst ziemlich verwirrt sind: EST hat die gleiche Zeit wie EDT‽

Sie können Benutzer mit einem kurzen Klappentext über die Sommerzeit informieren und auf einen geeigneten Zeitkonvertierungs-Webservice verlinken, um den Nutzern zu helfen. Idealerweise sollten alle Zeitstempel die Option haben, in Ortszeit umgewandelt zu werden.

Wenn alles gesagt und getan ist, sollten Sie feststellen, dass ich den Elefanten im Raum die ganze Zeit ignoriert habe, und das ist die "Countdown" -Lösung, die Sie bereits implementiert haben. "In 1 Tag 2 Stunden 45 Minuten 47 Sekunden" ist nichts verwirrend (und wenn Sie glauben, dass Sie nicht so viel Präzision benötigen, möchten Sie vielleicht noch einmal darüber nachdenken ).

Sicher, meiner Erfahrung nach hatte ich nie den Luxus von etwas, das kein statischer Text war, also musste ich mit dem unglaublichen Durcheinander umgehen, das oben abgebildet ist (und das ist nur der Anfang davon! Wie wäre es mit der südlichen Emisphäre, die Sommerzeit rückwärts macht?) , aber für Ihren Anwendungsfall klingt es nach der Lösung mit dem geringsten Verwirrungspotential. Möglicherweise werden zwei Threads pro Jahr nach "in 23 Stunden" - und "in 25 Stunden" -Ereignissen gefragt, während normalerweise von "in 24 Stunden" heruntergezählt wird, aber das war's.