it-swarm.com.de

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

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

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

Vielen Dank

11
JT703

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. Zusammenfassend lässt sich sagen, dass viele Faktoren dazu beitragen, wie unterschiedliche Zeitzonen verarbeitet werden.

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

1) Speichern Sie alles, was mit einem Datum wie UTC zu tun hat, in der Datenbank ... und erlauben Sie den Benutzern auf Ihrer Website eine benutzerdefinierte Einstellung, um die Zeitzone auszuwählen, in der sie sich befinden ... oder führen Sie eine Geo-IP-Suche durch, um dies herauszufinden Wo auf der Welt sind sie und finden die passende Zeitzone ... 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 eingeben. (Nehmen Sie die Ortszeit und konvertieren Sie sie für die Datenbankspeicherung zurück in UTC.) Dies ist wahrscheinlich die am häufigsten verwendete Methode. Dies würde Ihnen auch viel Zeit sparen, wenn Sie versuchen, das Rad neu zu erfinden. Was anonyme Besucher angeht ... können Sie entweder A) bei EST/EDT bleiben (indem Sie die eingebauten Funktionsaufrufe für die Anzeige verwenden) oder B) zur Geo-IP-Lookup-Sache zurückkehren und eine Zeitzone basierend auf auswählen begründete Vermutung. Es ist auch eine gute Idee, immer die Zeitzone anzugeben, in der Sie Datum und Uhrzeit anzeigen. Sagen Sie also niemals "12:00". Stellen Sie sicher, dass "12:00 EDT" angezeigt wird.

oder 2) Befolgen Sie das StackExchange-Modell (und viele andere Modelle), um den Unterschied zwischen dem jetzigen und dem Zeitpunkt der Erstellung des Posts 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 ..." ausführen wird in vielen Situationen immer häufiger ... ist aber nicht so ideal für kalendertypische Zeitpläne.

Natürlich ... können Sie immer noch eine Art Hybrid aus beiden verwenden ... und müssen möglicherweise 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.

4
TheCompWiz

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

Folgendes passiert in dieser Zeit. Angenommen, Sie haben jeden Tag ein Ereignis zur gleichen Zeit 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 verwirren Amerikanische Kunden, die unterschiedliche UTC-Zeiten (gestern um 20 Uhr, heute um 19 Uhr) für dieselbe Wanduhrzeit sehen (gestern um 15 Uhr, heute wieder um 15 Uhr), und dann Ihre in der EU ansässigen Kunden, die nicht t sehen, wie sich die gemeldete Uhrzeit ändert, und müssen dennoch die Uhrzeit des Wanduhrereignisses ändern.

  • Wenn Sie die Zeit in einer globalen Zeitzone anzeigen und diese als GMT bezeichnen, können Sie nicht nur US-Kunden verwirren, sondern auch Kunden in Großbritannien, die von wechseln GMT nach BST. 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 werden).

  • Wenn Sie die Zeitzone in einer EU-Zeitzone anzeigen (ich habe MEZ/MESZ verwendet, um GMT/UTC-Verwirrung zu vermeiden), ist dies offensichtlich sehr verwirrend für Ihre Zeitzone US-Kunden, die die Ereigniszeit zweimal hin- und herwechseln sehen und dennoch keine Zeitumstellung der Wanduhr erleben, ä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-amerikanischen Zeitzone anzeigen (wie EST/EDT ), wird die oben erläuterte genaue Situation angezeigt, aber gespiegelt!

Dies scheint eine hoffnungslose Situation zu sein! Hier ist, wie ich kam, um es nach vier Jahren durchlaufen dieses rigmarole (zweimal im Jahr, offensichtlich) zu adressieren: "eine Zeitzone bilden."

Ich bin in genau der oben abgebildeten Situation, also habe ich "NYT" (New York Timezone) erfunden, damit ich "1500 NYT" schreiben kann, was "15 Uhr in welcher Zeitzone auch immer New York verwendet" bedeutet.

Dies hat den Vorteil, dass, solange der Benutzer weiß, dass der DST-Walzer ausgeführt wird, er eine sehr einfache Möglichkeit zum Umrechnen in seine eigene Zeitzone hat: google " time in new york " to Sehen Sie, wie spät es in NY ist, und arbeiten Sie es dann von dort aus aus. Sie können sogar ausgefallene und geolokalisierte Services wie time.is/15:00_in_New_York nutzen.

Beachten Sie, dass Sie zwar die Abkürzungen für die Zeitzone in time.is verwenden können, ich Sie jedoch auffordern, dies nicht zu tun, da sie selbst ziemlich verwirrt sind: EST hat die gleiche Zeit wie EDT

Sie können Benutzer über die Sommerzeit mit einem kurzen Klappentext benachrichtigen, indem Sie eine Verknüpfung zu einem geeigneten Zeitumwandlungs-Webservice herstellen, um den Benutzern zu helfen. Im Idealfall sollten alle Zeitstempel eine Option haben, die in Ortszeit umgewandelt werden kann.


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 nicht verwirrend (und wenn Sie glauben, dass Sie nicht so viel Präzision benötigen Sie möchten vielleicht noch einmal darüber nachdenken ).

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

8
badp