it-swarm.com.de

Wie kann ich mit Zeitzonen in meiner Webapplikation umgehen?

Ich suche nach einem besseren Verständnis der folgenden User Story:

John arbeitet in Sidney. Um 9:00 Uhr morgens protokolliert er ein Ereignis in einer Web-App, die auf einem Server in Zürich ausgeführt wird. Am nächsten Tag reist er zu einem Notfalltreffen nach New York, bei dem die Veranstaltung besprochen werden soll. Während des Meetings sucht er nach Datum und Uhrzeit nach dem Ereignis.

Aus meiner Sicht gibt es hier mindestens zwei Probleme:

  1. Wie soll ich die Zeitstempel in der Datenbank speichern?
  2. Wie soll ich sie in der Benutzeroberfläche darstellen?

Wenn John das Ereignis durchsucht, wird er wissen, dass es um 9:00 Uhr passiert ist, aber was sollte er in den Webbrowser eingeben? Er wird nichts finden, wenn er nur "9:00" als Zeitstempel eingibt, da dies möglicherweise die Zeit von Zürich oder New York ist (da das Ereignis nicht gefunden wurde, kann die App nicht wissen, dass es in Sidney passiert ist) es kann nicht automatisch die richtige Zeitzone auswählen).

Was ist eine gute Möglichkeit, den Benutzer nach einem Zeitstempel zu fragen, der möglicherweise die Zeitzone enthält?

Das zweite Problem ist, wie die Ergebnisse angezeigt werden. Wenn Teams aus der ganzen Welt über das Ereignis diskutieren müssen (und verwandte Ereignisse suchen, stellen Sie sich einen Cracker-Angriff vor, der auf mehrere Standorte auf der ganzen Welt gleichzeitig abzielt).

Was ist ein gutes Beispiel für die Anzeige von Zeitstempeln, die möglicherweise in einer anderen Zeitzone erstellt wurden?

Hinweis: Bitte konzentrieren Sie sich auf die Verwendbarkeit der Anforderung. Ich kann die Datenbankzuordnung selbst herausfinden. Derzeit bin ich mir nicht sicher über den Arbeitsablauf. Es sollte die notwendigen Informationen auf eine nicht aufdringliche/intuitive Art und Weise abfragen/präsentieren. Wenn Sie können, geben Sie einen Link zu einer vorhandenen Web-App, die dies bereits löst.

89
Aaron Digulla

Das Speichern von Zeitstempeln ist ganz einfach: Speichern Sie sie in UTC.

Für die Anzeige ist es sinnvoll, die Zeitzoneneinstellung des Geräts als aktuelle Zeitzone zu verwenden. Das heißt, neben dem Feld "Zeiteingabe" sollte ein Dropdown-Menü für die Zeitzone angezeigt werden, das standardmäßig die aktuelle Zeitzone des Geräts angibt, damit der Benutzer sie bei Bedarf ändern kann.

Die Mehrheit Ihrer Benutzer wird die Zeitzonen wahrscheinlich kaum oder gar nicht ändern. In den meisten Fällen ist die von Ihnen beschriebene Situation ungewöhnlich. Wenn Sie ein Dropdown-Menü mit einer geeigneten Standardeinstellung implementieren, sollten Sie in der Lage sein, denjenigen, die sich fortbewegen, die Dinge so einfach wie möglich zu machen (da sie in der Regel die Zeitzonen besser verstehen als ein Nicht-Reisender).

Noch besser wäre es, die Zeitzone zu speichern, auf die das Gerät eingestellt war, als Ihre App zum ersten Mal ausgeführt wurde, und dann zu prüfen, ob sie sich jemals ändert. Wenn es sich ändert, ist der Benutzer wahrscheinlich ein Reisender und würde wahrscheinlich von der Dropdown-Liste der Zeitzonen profitieren. Andernfalls wird das Dropdown-Menü und die Standard-Zeitzone des Geräts nicht angezeigt (da der Benutzer nichts darüber wissen muss). In beiden Fällen müssen Sie in der App eine Einstellung vornehmen, mit der der Benutzer das Dropdown-Menü für die Zeitzone manuell ein-/ausblenden kann.


Um das Obige zusammenzufassen:

  • Speichern Sie beim ersten Start die Zeitzone, auf die das Gerät eingestellt ist.
  • Verwenden Sie diese Zeitzone als Standard-Zeitzone. Nehmen Sie immer diese Zeitzone an.
  • Wenn das Gerät die Zeitzone wechselt, fügen Sie ein Dropdown-Menü hinzu, um auszuwählen, in welcher Zeitzone sich das Ereignis befindet. Standardmäßig wird die Zeitzone des Geräts verwendet.
  • Fügen Sie eine Option hinzu, um dieses Zeitzonen-Dropdown manuell anzuzeigen/auszublenden.
  • Speichern Sie Zeitstempel immer in UTC.
84

In unseren Anwendungen speichern wir im Allgemeinen die Zeitzone des Benutzers, wenn wir uns zum ersten Mal registrieren, wie dies häufig auf Forenseiten zu sehen ist, und immer die Zeit mit der Zeitzone anzeigen.

Zum Speichern der Daten ist UTC die richtige Wahl. In UTC konvertieren und in die Datenbank übernehmen. Konvertieren Sie beim Abrufen einfach die Zeit in die für den Benutzer festgelegte Zeitzone.

Ich musste einen ähnlichen Anwendungsfall lösen, bei dem benutzerdefinierte Benachrichtigungen wie "Frohes Neues Jahr" an alle Benutzer der Web-App gesendet werden konnten. Da die Benutzer weltweit verteilt sind, mussten wir die Benachrichtigung entsprechend der Zeitzone anzeigen. Das Speichern des Zeitstempels in UTC hat unseren Zweck erfüllt, ohne dass es zu Problemen kommt.

Wenn Sie in Ihrem Anwendungsfall die Benutzer-Zeitzone nicht an einem Ort speichern, können Sie Ihre Suchergebnisse nur dann korrekt zurückgeben, wenn Sie nach Benutzereingaben fragen, wie dies bei gmaps der Fall ist. t zuverlässig. Sie müssen also jedes Mal nach der Zeitzone fragen, um sicherzustellen, dass der Benutzer weiß, was er auf der Website eingibt.

Wenn Sie über Zeitzoneninformationen verfügen, sollte die gesamte Web-App mit der Zeitzoneneinstellung ausgeführt werden. Wenn der Benutzer also nach 9:00 sucht, sucht er mit der Sydney-Zeitzone. Wenn er hingegen ein Ereignis erstellt, während er in New York sitzt, erstellt er ein Ereignis mit der Sydney-Zeitzone. Wir lösen solche Fälle, indem wir bei der Datumsanzeige immer die Zeitzone anzeigen.

Ich hoffe es hilft! :)

19
Varun Achar
  1. KOORDINIERTE WELTZEIT. Halte es einfach.

  2. Verwenden Sie die Zeitzone, die für den Benutzer am relevantesten ist.

    Wenn Sie wissen, dass der Benutzer für die Veranstaltung in Sydney ist oder nach Sydney reist, befindet er sich nachdenklich in dieser Zeitzone, wenn er den Transport zur Veranstaltung arrangiert. Die Tatsache, dass sie derzeit in New York sind, spielt keine Rolle. Und wenn Ihre App Daten in verschiedenen Zeitzonen anzeigt, sollte sie natürlich immer die Zeitzone neben dem Datum anzeigen, z. 9:00 EST.

    Wenn Ihre Benutzeroberfläche nicht zu überladen ist, können Sie Datumsangaben in der Zeitzone des Ereignisses und in der lokalen Zeitzone anzeigen, z. 2012-06-13 09:00 EST (2012-06-12 19:00 EDT).

    Ich würde argumentieren, dass das Suchen ein ähnliches Problem ist, mit einer Einschränkung: Wir können falsche Positive tolerieren (ein Ergebnis zu erhalten, das wir nicht erwartet hatten), aber wir können falsche Negative nicht ertragen (kein Ergebnis zu erhalten, das wir erwartet hatten).

    Ich würde mich wieder darauf konzentrieren, die für den Benutzer relevanteste Zeitzone zu suchen (z. B. Ereignis-Zeitzone) und diesen Ergebnissen in den Suchergebnissen Priorität einzuräumen. Sie können jedoch auch Ereignisse zurückgeben, die mit anderen für den Benutzer relevanten Zeitzonen übereinstimmen (z. B. Ortszeit). Wenn Sie dies tun, sollten Sie das Ereignisdatum in der entsprechenden Zeitzone anzeigen, insbesondere wenn Sie übereinstimmenden Text markieren.

10
Richard Poole

Hier gebe ich Vorschläge für die beste Benutzerfreundlichkeit, ohne mich um die Durchführbarkeit der Implementierung zu kümmern.
1. Bei der ersten Ausgabe des Speicherns von Ereignissen in db würde jeder zustimmen, diese in UTC zu speichern

2. Um die bestmögliche Benutzererfahrung zu erzielen, speichern Sie den Verlauf der Zeitzone des Benutzers. Wenn Sie den Zeitstempel der Zeitzonenänderung speichern könnten, noch besser. Auf diese Weise können wir dem Benutzer die Freiheit geben, Abfragen durchzuführen, ohne jedes Mal die Zeitzone explizit anzugeben.

Lassen Sie uns mit diesen Funktionen sehen, wie Suchanfragen von nur "9.00" von John behandelt werden:
Mit den oben genannten Funktionen weiß ich jetzt, dass John in 2 Zeitzonen bis zum Datum war (oder eine Zeitzonenliste für den genannten Zeitraum erhalten hat). Also werde ich 9.00 Uhr von der Zeitzone in Sydney nach UTC umwandeln und eine Abfrage starten. Konvertieren Sie außerdem 9.00 von der NewYork-Zeitzone in UTC, und führen Sie eine Abfrage durch. Als Ergebnis zeige ich John zwei Zeilen, in denen er anzeigt, was er um 9.00 Uhr in Sydney und um 9.00 Uhr in New York getan hat. Die New Yorker Zeile ist in diesem Fall leer, aber ich denke, sie sollte dem Benutzer trotzdem angezeigt werden, nur um ihn darüber zu informieren, dass wir auch nach dieser Zeitzone gesucht haben.

3.Was ist eine gute Methode, um den Benutzer nach einem Zeitstempel zu fragen, der möglicherweise die Zeitzone enthält?

Wenn seine Zeitzone kürzlich geändert wurde, sollte bei jeder Anmeldung bei der Anwendung eine Benachrichtigung erfolgen, dass Ihre Standardzeitzone in die native Zeitzone geändert wird.
Nehmen wir an, der Benutzer wählt beim Erstellen eines Ereignisses die Zeitzone aus der Dropdown-Liste aus. Der Benutzer wird nicht belastet, indem er Optionen für alle Zeitzonen der Welt angibt. Die erste Dropdown-Option sollte die aktuelle Zeitzone des Geräts des Benutzers sein. danach Zeitzonen aus seiner Zeitzonenhistorie, dann UTC und dann verbleibende Zeitzonen, die er bis dato nie benutzt hat.

4. So zeigen Sie die Ergebnisse an, wenn Teams aus der ganzen Welt über das Ereignis diskutieren müssen:

Ich möchte diesen Anwendungsfall auf die Anzahl der Teams 2 oder mehr als 2 aufteilen.
Bei nur 2 Teams würde ich es vorziehen, wenn jedes Team einen Zeitstempel in seiner lokalen Zeitzone und in der Zeitzone des anderen Teams sieht. (Ich persönlich bevorzuge es, in der Zeitzone einer Person am anderen Ende zu sprechen, um eine Besprechung zu planen). Für mehr als 2 Teams ist es besser, eine häufigere Zeitzone zu berücksichtigen, d. H. UTC. In diesem Fall sollte jeder Benutzer den Zeitstempel in 2 Zeitzonen, in UTC und in seiner Standardzeitzone sehen.

Diese Vorschläge werden mit der Absicht gemacht, dass der Benutzer keine Berechnung in seiner Ortszeit durchführen muss, aber gleichzeitig in der Lage sein sollte, mit anderen Benutzern in ihrer bevorzugten Zeitzone fließend zu kommunizieren.

7
Pranalee

Ok, ich habe einen anderen Ansatz als andere:

Erstens habe ich einige Dinge vorher angenommen.

Die Person, die eine Veranstaltung auflistet, hat ein Smartphone (wenn es sich um einen Browser handelt, muss ich diese Annahmen nicht treffen) mit:

  1. Geographisches Positionierungs System

  2. HTML5-Fähigkeit.

  3. Javascript-Fähigkeit

Wie soll ich die Zeitstempel in der Datenbank speichern?

Lösung: Offensichtlich [~ # ~] utc [~ # ~] Ich überlagerte folgende Prozedur:

Schritt 1. Verwenden Sie die Geolocation des Benutzers, der die Geolocation-API verwendet

    window.onload = getMyLocation;

    function getMyLocation() {
        if (navigator.geolocation) {
            navigator.geolocation.getCurrentPosition(displayLocation);
        } else {
            alert("Oops, no geolocation support");
        }
    }

    function displayLocation(position) {
        var latitude = position.coords.latitude;
        var longitude = position.coords.longitude;
        var div = document.getElementById("location");
        div.innerHTML = "You are at Latitude: " + latitude + ", Longitude: " + longitude;
    }

Schritt 2. Geben Sie (Long, Lat) als Argumente für einige der (Lat, Long) zu TimeZone-APIs wie Yahoo API (verwenden Sie Flag R, um die Latitude in Timezone umzuwandeln), um die zu erhalten Benutzer Zeitzone.

=> Die Zeitzone des Benutzers wird ohne Benutzereingabe bestimmt (Ich verwende dies, weil Sie nicht einfach davon ausgehen können, dass der Benutzer die Zeitzone des Ortes kennt, in dem er lebt, I kannte meine Zeitzone erst nach ein paar Monaten oder so vor Ort: P, ganz schön doof!)

Jede Ereignistabelle hat Timezone, Event & kann daher auch CityName haben. Erstellen Sie dann eine andere Datenbanktabelle mit einer Klassifizierung basierend auf CityNames. Hier hat der Benutzer also zwei Spalten

|---------------------------------------|
|_____NewYork________|______Sydney______|
|                    |                  |
|Event 1             |  Event 2         |
|____________________|__________________| 

Für die Benutzeroberfläche

=> Google Kalender-API oder einige der Kalender-APIs verwenden

Verwandte Lesungen:

  1. Ermitteln Sie die Zeitzone anhand des Breiten-/Längengrads, ohne Webdienste wie Geonames.org zu verwenden.

  2. Zeitzonensuche von der geografischen Breite bis zur geografischen Länge

Ich weiß, es geht nur darum, eine Idee zu zeigen, wie man dieses Problem löst. Aber sehen Sie, wie genau und leicht es für Benutzer wird, wenn die Zeitzone mithilfe von Geräte-APIs bestimmt wird

Ich hoffe es hilft!

4
uday
  1. Wie soll ich die Zeitstempel in der Datenbank speichern?

Bei der Ereigniserstellung würde ich die UTC-Zeit und die lokale Zeitzone (auch bekannt als creation time zone) Speichern. Ich würde das, was ich gespeichert habe, verwenden, um die UTC-Zeit in die Ortszeit umzuwandeln (auch bekannt als creation time) Und es neben der UTC-Zeit und creation time zone Zu speichern.

HINWEIS: Ich kann die Ortszeit von Anfang an speichern, aber wenn der Benutzer nach einem Ereignis sucht, würde ich hoffen, dass eine Umstellung auf die Ortszeit vorliegt. Ich hoffe auch, dass der Server erkennen kann, in welcher Zeitzone sich der Client befindet.

  1. Wie soll ich sie in der Benutzeroberfläche darstellen?

Wenn ein Benutzer nach "9:00" sucht, suche ich nach Ereignissen, die "9:00" enthalten, entweder in UTC ODER creation time ODER Ortszeit. Für die Ergebnisse würde ich eine Ergebnistabelle in creation time Anzeigen (Dies soll Zeitstempel anzeigen, die möglicherweise in einer anderen Zeitzone erstellt wurden, da davon ausgegangen wird, dass der Benutzer nach dem Zeitpunkt sucht, zu dem er ein Ereignis erstellt hat und zeigen Sie unten eine zweite Ergebnistabelle mit verwandten Ergebnissen an, möglicherweise mit der Überschrift "Nicht das, wonach Sie suchen? Siehe verwandte Ergebnisse" (einschließlich der übrigen UTC- und Ortszeitergebnisse).

Insgesamt würde ich die UTC-Zeit, die Ortszeit, den creation time Und den creation time zone (Dh die Ortszeit und die Zeitzone des Ereignisses, in dem es erstellt wurde) nach UTC-Zeit sortiert anzeigen Sie können sehen, welches Ereignis zuerst eintrifft, falls zwei verschiedene Ereignisse für 9:00 Uhr in zwei verschiedenen Zeitzonen geplant waren.

2
user5398447

In diesem speziellen Fall würde ich beide lokale und UTC-Zeit speichern. UTC ist etwas wichtiger und wird für die Synchronisierung und Konvertierung der Zeit in die aktuelle Zeitzone verwendet. Lokal wird für Suchanfragen und für zusätzliche Informationen verwendet, z.

Sie haben ein Treffen:

12:00 Monday (UTC)
9:00 Monday (Sydney, creation local time)
11:00 Monday (Zurich, local time)

oder etwas ähnliches. Die andere Möglichkeit besteht darin, die Erstellungszeitzone zu speichern und zur Laufzeit zu konvertieren (dies ist insbesondere dann besser, wenn der Benutzer die Besprechungszeit ändert). In beiden Fällen liegt der Hauptgrund darin, dass die ursprüngliche Erstellungszeit wiederhergestellt werden kann, damit der Benutzer darauf zugreifen kann.

2
Petr Abdulin