Frage Empfehlungen für die Sommerzeit und die Zeitzone [geschlossen]


Ich hoffe, diese Frage und die Antworten auf sie zu einem definitiven Leitfaden für den Umgang mit der Sommerzeit zu machen, insbesondere für den Umgang mit den tatsächlichen Umstellungen.

Wenn Sie etwas hinzuzufügen haben, tun Sie es bitte

Viele Systeme sind abhängig von der Einhaltung genauer Zeit, das Problem ist mit Änderungen der Zeit aufgrund von Tageslichteinsparungen - Bewegen der Uhr vorwärts oder rückwärts.

Zum Beispiel hat man Geschäftsregeln in einem Auftragsannahmesystem, die von der Zeit der Bestellung abhängig sind - wenn sich die Uhr ändert, sind die Regeln möglicherweise nicht so klar. Wie sollte der Zeitpunkt der Bestellung eingehalten werden? Es gibt natürlich eine endlose Anzahl von Szenarien - dieses ist nur eine illustrative.

  • Wie hast du das Thema Sommerzeit behandelt?
  • Welche Annahmen sind Teil Ihrer Lösung? (Suche hier nach Kontext)

So wichtig, wenn nicht noch wichtiger:

  • Was hast du versucht, das hat nicht funktioniert?
  • Warum hat es nicht funktioniert?

Ich würde mich für die Programmierung, Betriebssystem, Datenpersistenz und andere relevante Aspekte des Problems interessieren.

Allgemeine Antworten sind großartig, aber ich würde auch gerne Details sehen, besonders wenn sie nur auf einer Plattform verfügbar sind.


1885


Ursprung


Antworten:



Zusammenfassung der Antworten und anderer Daten: (bitte fügen Sie Ihre hinzu)

Machen:

  • Wenn Sie sich auf einen genauen Zeitpunkt beziehen, behalten Sie die Zeit gemäß einem einheitlichen Standard bei, der nicht durch die Sommerzeit beeinflusst wird. (GMT und UTC sind in dieser Hinsicht gleichwertig, aber es wird bevorzugt, den Begriff UTC zu verwenden. Beachten Sie, dass UTC auch als Zulu- oder Z Zeit.)
  • Wenn Sie stattdessen eine Zeit mit einem lokalen Zeitwert beibehalten möchten, berücksichtigen Sie den lokalen Zeitversatz für diese bestimmte Zeit aus UTC (dieser Offset kann sich im Laufe des Jahres ändern), sodass der Zeitstempel später eindeutig interpretiert werden kann.
  • In einigen Fällen müssen Sie möglicherweise speichern beide die UTC-Zeit und die entsprechende Ortszeit. Oft wird dies mit zwei getrennten Feldern gemacht, aber einige Plattformen unterstützen a datetimeoffset Typ, der beide in einem einzigen Feld speichern kann.
  • Wenn Sie Zeitstempel als numerischen Wert speichern, verwenden Sie Unix-Zeit - Das ist die Anzahl der ganzen Sekunden seit 1970-01-01T00:00:00Z (ausgenommen Schaltsekunden). Wenn Sie eine höhere Genauigkeit benötigen, verwenden Sie stattdessen Millisekunden. Dieser Wert sollte immer auf UTC basieren, ohne Zeitzonenanpassung.
  • Wenn Sie den Zeitstempel später ändern müssen, fügen Sie die ursprüngliche Zeitzonen-ID hinzu, damit Sie feststellen können, ob sich der Offset gegenüber dem ursprünglichen Wert geändert hat.
  • Bei der Planung zukünftiger Ereignisse wird in der Regel die lokale Zeit anstelle von UTC bevorzugt, da sich der Offset normalerweise ändert. Siehe Antwort, und Blogeintrag.
  • Speichern Sie ganze Daten wie Geburtstage und Jahrestage nicht in UTC oder in eine andere Zeitzone.
    • Wenn möglich, speichern Sie in einem Nur-Datum-Datentyp, der keine Uhrzeit enthält.
    • Wenn ein solcher Typ nicht verfügbar ist, achten Sie darauf, die Uhrzeit immer zu ignorieren, wenn Sie den Wert interpretieren. Wenn Sie nicht sicher sein können, dass die Uhrzeit ignoriert wird, wählen Sie 12:00 Uhr statt 00:00 Uhr Mitternacht als eine sicherere repräsentative Zeit an diesem Tag.
  • Denken Sie daran, dass Zeitzonen-Offsets nicht immer eine ganze Zahl von Stunden sind (z. B. ist die indische Standardzeit UTC + 05: 30 und Nepal verwendet UTC + 05: 45).
  • Wenn Sie Java verwenden, verwenden Sie java.time für Java 8 oder verwenden Joda Zeit für Java 7 oder niedriger.
  • Wenn Sie verwenden .NETZ, in Betracht ziehen, zu verwenden Noda Zeit.
  • Wenn Sie .NET ohne Noda Time verwenden, beachten Sie das DateTimeOffset ist oft eine bessere Wahl als DateTime.
  • Wenn Sie Perl verwenden, verwenden Sie Terminzeit.
  • Wenn Sie Python verwenden, verwenden Sie pytz oder Datum.
  • Wenn Sie JavaScript verwenden, verwenden Sie moment.js mit dem Moment-Zeitzone Erweiterung.
  • Verwenden Sie bei Verwendung von PHP> 5.2 die nativen Zeitzonen-Konvertierungen von DateTime, und DateTimeZone Klassen. Sei vorsichtig beim Benutzen DateTimeZone::listAbbreviations() - siehe Antwort. Um PHP mit aktuellen Olson-Daten zu versorgen, installieren Sie es regelmäßig der Zeitzonedb PECL-Paket; siehe Antwort.
  • Wenn Sie C ++ verwenden, stellen Sie sicher, dass Sie eine Bibliothek verwenden, die das ordnungsgemäß implementiert IANA Zeitzone Datenbank. Diese beinhalten cctz, Intensivstation, und Howard Hinnants "tz" -Bibliothek.
    • Verwende nicht Boost für Zeitzonenumwandlungen. Während seine API behauptet, Standard IANA (alias "zoneinfo") Identifikatoren zu unterstützen kategorisiert sie grob zu POSIX-style Daten, ohne Berücksichtigung der reichen Geschichte der Änderungen, die jede Zone gehabt haben könnte. (Außerdem wurde die Datei nicht mehr gewartet.)
  • Die meisten Geschäftsregeln verwenden zivile Zeit statt UTC oder GMT. Planen Sie daher die Konvertierung von UTC-Zeitstempeln in eine lokale Zeitzone vor dem Anwenden der Anwendungslogik.
  • Beachten Sie, dass Zeitzonen und Offsets nicht festgelegt sind und sich ändern können. Zum Beispiel verwendeten die USA und Großbritannien historisch dieselben Daten, um "vorwärts zu springen" und "zurückzufallen". Im Jahr 2007 haben die USA jedoch die Daten geändert, an denen die Uhren geändert werden. Dies bedeutet nun, dass für 48 Wochen des Jahres der Unterschied zwischen London Zeit und New York Zeit 5 Stunden und für 4 Wochen (3 im Frühjahr, 1 im Herbst) ist es 4 Stunden. Achten Sie bei Berechnungen mit mehreren Zonen auf solche Elemente.
  • Berücksichtigen Sie die Art der Zeit (tatsächliche Ereigniszeit, Sendezeit, relative Zeit, historische Zeit, wiederkehrende Zeit), welche Elemente (Zeitstempel, Zeitzonenoffset und Zeitzonenname) Sie für den korrekten Abruf speichern müssen - siehe "Zeittypen" in diese Antwort.
  • Halten Sie Ihre OS-, Datenbank- und Anwendungs-tzdata-Dateien synchron mit sich selbst und dem Rest der Welt.
  • Setzen Sie auf Servern die Hardwareuhren und Betriebssystemuhren auf UTC und nicht auf eine lokale Zeitzone.
  • Ungeachtet des vorherigen Aufzählungspunkts serverseitiger Code, einschließlich Websites, sollte noch nie erwarten Sie, dass die lokale Zeitzone des Servers etwas Besonderes ist. siehe Antwort.
  • Arbeiten Sie lieber im Einzelfall in Ihrem Anwendungscode mit Zeitzonen und nicht global über die Einstellungen oder Standardeinstellungen der Konfigurationsdatei.
  • Benutzen NTP Dienste auf allen Servern.
  • Wenn Sie verwenden FAT32Denken Sie daran, dass Zeitstempel in der lokalen Zeit und nicht in UTC gespeichert werden.
  • Berücksichtigen Sie bei wiederkehrenden Ereignissen (z. B. wöchentliche Fernsehshow), dass sich die Uhrzeit mit der Sommerzeit ändert und in den verschiedenen Zeitzonen unterschiedlich ist.
  • Abfragen von Datum-Uhrzeit-Werten immer als Untergrenze inklusive, Obergrenze exklusiv (>=, <).

Nicht:

  • Verwechseln Sie keine "Zeitzone", wie z America/New_York mit einem "Zeitzonen-Offset", wie z -05:00. Sie sind zwei verschiedene Dinge. Sehen das Zeitzonen-Tag-Wiki.
  • Verwenden Sie kein JavaScript Date Objekt, um Datums- und Zeitberechnungen in älteren Webbrowsern durchzuführen, wie ECMAScript 5.1 und niedriger ein Designfehler das kann die Sommerzeit falsch verwenden. (Dies wurde in ECMAScript 6/2015 behoben).
  • Traue niemals der Uhr des Kunden. Es kann sehr wohl falsch sein.
  • Sag den Leuten nicht, dass sie "UTC überall benutzen" sollen. Dieser umfassende Ratschlag ist kurzsichtig zu mehreren gültigen Szenarien, die weiter oben in diesem Dokument beschrieben wurden. Verwenden Sie stattdessen die entsprechende Zeitreferenz für die Daten, mit denen Sie arbeiten. (Zeitstempeln kann UTC verwenden, aber zukünftige Zeitplanung und Datumswerte sollten nicht.)

Testen:

  • Stellen Sie beim Testen sicher, dass Sie Länder im Westen, Osten, Norden und Nordirland testen Süd Hemisphären (in der Tat in jedem Viertel des Globus, also 4 Regionen), mit beiden DST im Gange und nicht (gibt 8), und ein Land, das DST nicht verwendet (weitere 4, um alle Regionen abzudecken, insgesamt 12).
  • Testen Sie den Übergang von DST, d. H. Wenn Sie sich gerade im Sommer befinden, wählen Sie einen Zeitwert aus dem Winter.
  • Testen Sie Grenzfälle, z. B. eine Zeitzone, die UTC + 12 ist, mit DST, um die lokale Zeit zu ermitteln UTC + 13 im Sommer und sogar Orte, die im Winter UTC + 13 sind
  • Testen Sie alle Bibliotheken und Anwendungen von Drittanbietern und stellen Sie sicher, dass sie die Zeitzonendaten korrekt verarbeiten.
  • Testen Sie mindestens eine halbe Stunde Zeitzonen.

Referenz:

Andere:

  • Feuere deinen Vertreter an, um die Gräuel, die DST ist, zu beenden. Wir können immer hoffen ...
  • Lobby für Erde Standardzeit

802



Ich bin nicht sicher, was ich zu den Antworten oben hinzufügen kann, aber hier sind ein paar Punkte von mir:

Arten von Zeiten

Es gibt vier verschiedene Zeiten, die Sie beachten sollten:

  1. Ereigniszeit: zB die Zeit, wenn ein internationales Sportereignis stattfindet, oder eine Krönung / Tod / etc. Dies ist abhängig von der Zeitzone des Ereignisses und nicht vom Betrachter.
  2. Fernsehzeit: Zum Beispiel wird eine bestimmte Fernsehsendung um 21 Uhr Ortszeit auf der ganzen Welt ausgestrahlt. Wichtig beim Nachdenken über die Veröffentlichung der Ergebnisse (von zB American Idol) auf Ihrer Website
  3. Relative Zeit: zB: Diese Frage hat ein offenes Kopfgeld, das in 21 Stunden endet. Dies ist einfach anzuzeigen
  4. Wiederkehrende Zeit: zB: Eine TV-Show ist jeden Montag um 21 Uhr, auch wenn sich die Sommerzeit ändert.

Es gibt auch historische / alternative Zeit. Diese sind ärgerlich, da sie möglicherweise nicht auf die Standardzeit zurückmelden. ZB: Julianische Daten, Daten nach einem Mondkalender auf Saturn, Der klingonische Kalender.

Das Speichern von Start- / End-Zeitstempeln in UTC funktioniert gut. Für 1 benötigen Sie einen Ereignis-Zeitzonennamen + Offset, der zusammen mit dem Ereignis gespeichert wird. Für 2 benötigen Sie eine lokale Zeitkennung, die für jede Region gespeichert ist, und einen lokalen Zeitzonennamen + Offset, der für jeden Betrachter gespeichert wird (es ist möglich, dies von der IP abzuleiten, wenn Sie sich in einer Krise befinden). Für 3, speichern in UTC Sekunden und keine Notwendigkeit für Zeitzonen. 4 ist ein Sonderfall von 1 oder 2, abhängig davon, ob es sich um ein globales oder ein lokales Ereignis handelt, aber Sie müssen auch ein hergestellt in Zeitstempel, sodass Sie feststellen können, ob sich eine Zeitzonendefinition vor oder nach dem Erstellen dieses Ereignisses geändert hat. Dies ist notwendig, wenn Sie historische Daten anzeigen müssen.

Speicherzeiten

  • Speichern Sie die Zeit immer in UTC
  • In lokale Zeit auf dem Display umrechnen (lokal wird vom Benutzer definiert, der die Daten betrachtet)
  • Wenn Sie eine Zeitzone speichern, benötigen Sie den Namen, den Zeitstempel und den Offset. Dies ist erforderlich, weil Regierungen manchmal die Bedeutungen ihrer Zeitzonen ändern (zB: die US-Regierung änderte DST-Daten), und Ihre Anwendung muss die Dinge elegant behandeln ... zB: Der genaue Zeitstempel, wenn LOST-Episoden sowohl vor als auch nach den DST-Regeln auftraten geändert.

Offsets und Namen

Ein Beispiel für das obige wäre:

Das Fußball-WM-Finale Spiel   passierte in Südafrika (UTC + 2 - SAST)   am 11. Juli 2010 um 19:00 UTC.

Mit diesen Informationen können wir historisch den genauen Zeitpunkt ermitteln, zu dem die WCS-Endrunde 2010 stattfand, selbst wenn sich die südafrikanische Zeitzonen-Definition ändert. und in der Lage sein, dies den Betrachtern in ihrer lokalen Zeitzone zu dem Zeitpunkt anzuzeigen, an dem sie die Datenbank abfragen.

Systemzeit

Außerdem müssen Sie Ihre OS-, Datenbank- und Anwendungs-tzdata-Dateien sowohl untereinander als auch mit dem Rest der Welt synchronisieren und ausgiebig testen, wenn Sie ein Upgrade durchführen. Es ist nicht unbekannt, dass eine Drittanbieter-App, auf die Sie angewiesen sind, eine TZ-Änderung nicht korrekt gehandhabt hat.

Stellen Sie sicher, dass die Hardware-Uhren auf UTC eingestellt sind. Wenn Sie Server auf der ganzen Welt betreiben, stellen Sie sicher, dass ihre Betriebssysteme auch für die Verwendung von UTC konfiguriert sind. Dies wird offensichtlich, wenn Sie stündlich gedrehte Apache-Protokolldateien von Servern in mehreren Zeitzonen kopieren müssen. Das Sortieren nach Dateiname funktioniert nur, wenn alle Dateien mit derselben Zeitzone benannt sind. Es bedeutet auch, dass Sie keine Datumsberechnung in Ihrem Kopf durchführen müssen, wenn Sie von einer Box zur nächsten springen und Zeitstempel vergleichen müssen.

Führen Sie auch ntpd auf allen Boxen aus.

Kunden

Traue niemals dem Zeitstempel, den du von einem Client-Rechner erhältst, als gültig. Zum Beispiel das Datum: HTTP-Header oder ein Javascript Date.getTime() Anruf. Diese sind in Ordnung, wenn sie als undurchsichtige Bezeichner verwendet werden oder wenn während einer einzelnen Sitzung auf demselben Client eine Datumsberechnungsmethode durchgeführt wird. Versuchen Sie jedoch nicht, diese Werte mit einem Wert zu verknüpfen, den Sie auf dem Server haben. Ihre Clients führen NTP nicht aus und verfügen möglicherweise nicht über eine funktionierende Batterie für ihre BIOS-Uhr.

Wissenswertes

Schließlich werden Regierungen manchmal sehr seltsame Dinge tun:

Standardzeit in den Niederlanden war   genau 19 Minuten und 32,13 Sekunden   vor UTC per Gesetz vom 1909-05-01   bis 1937-06-30. Diese Zeitzone   kann nicht exakt mit dargestellt werden   das Format HH: MM.

Ok, ich denke ich bin fertig.


288



Dies ist ein wichtiges und überraschend schwieriges Thema. Die Wahrheit ist, dass es keinen vollständig befriedigenden Standard für die Dauer gibt. Zum Beispiel sind der SQL-Standard und das ISO-Format (ISO 8601) eindeutig nicht genug.

Vom konzeptionellen Standpunkt aus behandelt man normalerweise zwei Arten von Zeit-Datum-Daten, und es ist praktisch, sie zu unterscheiden (die obigen Standards nicht):physikalische Zeit" und "bürgerliche Zeit".

Ein "physikalischer" Zeitpunkt ist ein Punkt in der kontinuierlichen universellen Zeitlinie, mit dem sich die Physik befasst (natürlich ohne die Relativität zu beachten). Dieses Konzept kann z. B. in UTC ausreichend codiert werden (wenn Sie Schaltsekunden ignorieren können).

Eine "zivile" Zeit ist eine Datetime-Spezifikation, die zivilen Normen folgt: ein Zeitpunkt wird hier vollständig durch eine Reihe von Datetime-Feldern (Y, M, D, H, MM, S, FS) plus einer TZ (Zeitzonenspezifikation) angegeben (auch ein "Kalender", eigentlich; aber nehmen wir an, wir beschränken die Diskussion auf den Gregorianischen Kalender). Eine Zeitzone und ein Kalender ermöglichen es (prinzipiell), von einer Repräsentation zu einer anderen zu mappen. Aber zivile und physikalische Zeitmomente sind grundlegend verschiedene Arten von Größen, und sie sollten konzeptionell getrennt und unterschiedlich behandelt werden (eine Analogie: Arrays von Bytes und Zeichenketten).

Das Thema ist verwirrend, weil wir von diesen Arten von Ereignissen synonym sprechen und weil die bürgerlichen Zeiten politischen Veränderungen unterliegen. Das Problem (und die Notwendigkeit, diese Konzepte zu unterscheiden) wird für Ereignisse in der Zukunft offensichtlicher. Beispiel (aus meiner Diskussion genommen Hier.

John speichert in seinem Kalender eine Erinnerung für ein Ereignis zum Zeitpunkt des Datums 2019-Jul-27, 10:30:00, TZ =Chile/Santiago, (die GMT-4 versetzt hat, daher entspricht es UTC 2019-Jul-27 14:30:00). Aber eines Tages Zukünftig entscheidet das Land, den TZ-Offset auf GMT-5 zu ändern.

Jetzt, wenn der Tag kommt ... sollte diese Erinnerung auslösen

EIN) 2019-Jul-27 10:30:00 Chile/Santiago  = UTC time 2019-Jul-27 15:30:00 ?

oder

B) 2019-Jul-27 9:30:00 Chile/Santiago  = UTC time 2019-Jul-27 14:30:00 ?

Es gibt keine richtige Antwort, außer man weiß, was John konzeptionell meinte als er dem Kalender sagte "Bitte kling mich an 2019-Jul-27, 10:30:00 TZ=Chile/Santiago".

Meinte er eine "bürgerliche Datum-Zeit" ("wenn die Uhren in meiner Stadt erzählen 10:30 ")? In diesem Fall ist A) die richtige Antwort.

Oder meinte er einen "physikalischen Augenblick der Zeit", einen Punkt im Kontinuum Zeitlinie unseres Universums, sagen wir, "wenn die nächste Sonnenfinsternis passiert ". In diesem Fall ist die Antwort B) die richtige.

Einige Date / Time APIs haben diese Unterscheidung richtig gemacht: JodatimeDies ist die Grundlage der nächsten (dritten!) Java DateTime API (JSR 310).


81



Sorgen Sie für eine klare Trennung der Interessen in Bezug auf die Architektur - Sie müssen genau wissen, welche Ebene mit den Benutzern interagiert und müssen das Datum / die Zeit für die kanonische Darstellung (UTC) ändern. Nicht-UTC Datum-Uhrzeit ist Präsentation (folgt der lokalen Zeitzone des Benutzers), UTC-Zeit ist ein Modell (bleibt einzigartig für Back-End- und Mid-Tiers).

Ebenfalls, Entscheide, was deine eigentliche Zielgruppe ist, was du nicht bedienen musst und wo du die Grenze ziehst. Berühren Sie keine exotischen Kalender, es sei denn, Sie haben dort wichtige Kunden und betrachten dann separate Benutzerserver für diese Region.

Wenn Sie den Standort des Benutzers erfassen und pflegen können, verwenden Sie den Speicherort für eine systematische Datums- / Uhrzeit-Konvertierung (z. B. .NET-Kultur oder eine SQL-Tabelle), bieten Sie dem Endbenutzer jedoch die Möglichkeit, Überschreibungen auszuwählen, wenn Datum und Uhrzeit für Ihre Benutzer von Bedeutung sind.

Wenn es historische Prüfungsverpflichtungen gibt involviert (wie genau zu sagen, wenn Jo in AZ eine Rechnung vor 2 Jahren im September bezahlte) dann behalten Sie sowohl UTC als auch Ortszeit bei für die Aufzeichnung (Ihre Konvertierungstabellen ändern sich im Laufe der Zeit).

Definieren Sie die zeitbezogene Zeitzone für Daten, die in großen Mengen vorliegen - Wie Dateien, Webdienste usw. Sagen Sie East Coast Unternehmen hat Rechenzentrum in CA - Sie müssen fragen und wissen, was sie als Standard verwenden, anstatt das eine oder andere zu übernehmen.

Vertrauen Sie den in die textliche Darstellung von Datum und Uhrzeit eingebetteten Zeitzonenoffsets nicht Akzeptiere nicht, sie zu analysieren und ihnen zu folgen. Verlangen Sie stattdessen immer, dass Zeitzone und / oder Referenzzone explizit definiert werden müssen. Sie können leicht Zeit mit PST-Offset erhalten, aber die Zeit ist tatsächlich EST, da dies die Referenzzeit des Clients ist und Datensätze wurden nur auf einem Server exportiert, der in PST ist.


53



Sie müssen über den Olson wissen TZ-Datenbank, die verfügbar ist von ftp://elsie.nci.nih.gov/pub  http://iana.org/time-zones/. Es wird mehrmals pro Jahr aktualisiert, um die häufig in letzter Minute auftretenden Änderungen zu berücksichtigen, wann (und ob) zwischen Winter- und Sommerzeit (Standard und Sommerzeit) in verschiedenen Ländern der Welt umgeschaltet wird. Im Jahr 2009 war die letzte Veröffentlichung 2009s; 2010 war es 2010n; 2011 war es 2011n; Ende Mai 2012 war die Veröffentlichung 2012c. Beachten Sie, dass in zwei separaten Archiven (tzcode20xxy.tar.gz und tzdata20xxy.tar.gz) ein Code zur Verwaltung der Daten und der eigentlichen Zeitzonendaten selbst vorhanden ist. Sowohl Code als auch Daten sind in der Public Domain.

Dies ist die Quelle von Zeitzonennamen wie America / Los_Angeles (und Synonyme wie US / Pacific).

Wenn Sie verschiedene Zonen im Auge behalten möchten, benötigen Sie die Olson-Datenbank. Wie andere empfohlen haben, möchten Sie die Daten auch in einem festen Format speichern - normalerweise wird UTC gewählt - und gleichzeitig die Zeitzone aufzeichnen, in der die Daten generiert wurden. Sie möchten vielleicht den Offset von UTC zum Zeitpunkt und den Namen der Zeitzone unterscheiden; das kann später einen Unterschied machen. Auch das Wissen, dass es derzeit 2010-03-28T23: 47: 00-07: 00 (US / Pazifik) ist, kann Ihnen bei der Interpretation des Werts 2010-11-15T12: 30 - der vermutlich in PST ( Pacific Standard Time) anstelle von PDT (Pacific Daylight Saving Time).

Die Standard-C-Bibliothek Schnittstellen sind nicht schrecklich hilfreich mit dieser Art von Sachen.


Die Olson-Daten haben sich verschoben, teilweise weil A D Olson bald in Rente gehen wird, und teilweise, weil es eine (jetzt entlassene) Klage gegen die Betreuer wegen Urheberrechtsverletzung gab. Die Zeitzonendatenbank wird jetzt unter der Schirmherrschaft von IANA, die Internet Assigned Numbers Authority, und es gibt einen Link auf der Startseite 'Zeitzonendatenbank'. Die Diskussions-Mailingliste ist jetzt tz@iana.org; Die Ankündigungsliste ist tz-announce@iana.org.


38



Im Algemeinen, den lokalen Zeitversatz einbeziehen (einschließlich DST-Offset) in gespeicherten Zeitstempeln: UTC allein reicht nicht aus, wenn Sie später den Zeitstempel in seiner ursprünglichen Zeitzone (und DST-Einstellung) anzeigen möchten.

Beachten Sie, dass der Offset nicht immer eine ganze Zahl von Stunden ist (z. B. indische Standardzeit ist UTC + 05: 30).

Zum Beispiel sind geeignete Formate ein Tupel (Unix-Zeit, Offset in Minuten) oder ISO 8601.


24



Die Grenze von "Computerzeit" und "Menschenzeit" zu überschreiten ist ein Albtraum. Der Hauptgrund dafür ist, dass es für die Regeln für Zeitzonen und Sommerzeit keine einheitliche Norm gibt. Länder können ihre Zeitzonen- und DST-Regeln jederzeit ändern, und das tun sie auch.

Einige Länder, z.B. Israel, Brasilien, entscheidet jedes Jahr über die Sommerzeit, so dass es unmöglich ist, im Voraus zu wissen, wann (wenn) die Sommerzeit in Kraft tritt. Andere haben (ish) Regeln, wann DST in Kraft ist. Andere Länder verwenden DST nicht als alle.

Zeitzonen müssen keine vollen Stunden von GMT abweichen. Nepal ist +5,45. Es gibt sogar Zeitzonen, die +13 sind. Das bedeutet, dass:

SUN 23:00 in Howland Island (-12)
MON 11:00 GMT 
TUE 00:00 in Tonga (+13)

sind alle gleichzeitig, noch 3 verschiedene Tage!

Es gibt auch keinen klaren Standard für die Abkürzungen für Zeitzonen, und wie sie sich in der Sommerzeit ändern, so dass Sie mit solchen Dingen enden:

AST Arab Standard Time     UTC+03
AST Arabian Standard Time  UTC+04
AST Arabic Standard Time   UTC+03

Der beste Rat ist, so weit wie möglich von der lokalen Zeit wegzubleiben und sich an UTC zu halten, wo es möglich ist. Konvertieren Sie nur zum letzten möglichen Zeitpunkt in lokale Zeiten.

Stellen Sie beim Testen sicher, dass Sie die Länder in der westlichen und östlichen Hemisphäre testen, wobei sowohl die Sommerzeit in Bearbeitung ist als auch nicht und ein Land, das die Sommerzeit nicht verwendet (insgesamt 6).


22



Für PHP:

Die DateTimeZone-Klasse in PHP> 5.2 basiert bereits auf der Olson-DB, die andere erwähnen. Wenn Sie also Zeitzonen-Konvertierungen in PHP und nicht in der DB durchführen, müssen Sie nicht mit (den schwer verständlichen) Olson-Dateien arbeiten.

PHP wird jedoch nicht so häufig aktualisiert wie die Olson-Datenbank. Wenn Sie also nur Zeitzonen-Konvertierungen von PHP verwenden, können Sie veraltete DST-Informationen hinterlassen und die Korrektheit Ihrer Daten beeinflussen. Obwohl dies nicht häufig erwartet wird, kann es passieren, und werden passieren, wenn Sie eine große Anzahl von Benutzern weltweit haben.

Um das obige Problem zu lösen, verwenden Sie die timezonedb pecl Paket, das ist die Funktion, um die Zeitzonendaten von PHP zu aktualisieren. Installieren Sie dieses Paket so oft wie es aktualisiert wurde. (Ich bin mir nicht sicher, ob diese Paketupdates Olson-Updates genau folgen, aber es scheint in einer Häufigkeit aktualisiert zu werden, die Olson-Updates zumindest sehr nahe kommt.)


18



Wenn Ihr Design es aufnehmen kann, Vermeiden Sie lokale Zeitumstellung alle zusammen! 

Ich weiß, dass dies verrückt klingt, aber denke an UX: Nutzer verarbeiten nahe, relative Daten (heute, gestern, nächster Montag) schneller als absolute Daten (2010.09.17, Freitag, 17. September) auf den ersten Blick. Und wenn Sie mehr darüber nachdenken, ist die Genauigkeit der Zeitzonen (und DST) umso wichtiger, je näher das Datum liegt now()Wenn Sie Datumsangaben / Datumsangaben in einem relativen Format für +/- 1 oder 2 Wochen ausdrücken können, können die übrigen Daten UTC sein und 95% der Benutzer sind nicht zu wichtig.

Auf diese Weise können Sie alle Daten in UTC speichern und die relativen Vergleiche in UTC durchführen und einfach die Benutzer-UTC-Daten außerhalb Ihres relativen Datumsschwellenwerts anzeigen.

Dies kann auch für Benutzereingaben gelten (jedoch im Allgemeinen in einer eingeschränkteren Art und Weise). Die Auswahl aus einer Dropdown-Liste mit nur {Gestern, Heute, Morgen, Nächsten Montag, Nächsten Donnerstag} ist für den Benutzer so viel einfacher und einfacher als eine Datumsauswahl. Date Pickers gehören zu den schmerzlindernden Komponenten der Formfüllung. Natürlich wird dies nicht für alle Fälle funktionieren, aber Sie können sehen, dass es nur ein wenig cleveres Design braucht, um es sehr leistungsfähig zu machen.


15



Während ich es nicht versucht habe, wäre ein Ansatz für Zeitzonenanpassungen, den ich für zwingend halten würde, folgender:

  1. Speichern Sie alles in UTC.

  2. Erstellen Sie eine Tabelle TZOffsets mit drei Spalten: RegionClassId, StartDateTime und OffsetMinutes (int, in Minuten).

Speichern Sie in der Tabelle eine Liste mit Datum und Uhrzeit wann die Ortszeit hat sich geändert und um wieviel. Die Anzahl der Regionen in der Tabelle und die Anzahl der Daten hängt davon ab, in welchem ​​Bereich von Daten und Gebieten der Welt Sie Unterstützung benötigen. Stellen Sie sich das so vor, als wäre es ein "historisches" Datum, auch wenn die Daten die Zukunft auf ein praktisches Limit begrenzen sollten.

Wenn Sie die Ortszeit einer UTC-Zeit berechnen müssen, tun Sie dies einfach:

SELECT DATEADD('m', SUM(OffsetMinutes), @inputdatetime) AS LocalDateTime
FROM   TZOffsets
WHERE  StartDateTime <= @inputdatetime
       AND RegionClassId = @RegionClassId;

Möglicherweise möchten Sie diese Tabelle in Ihrer App zwischenspeichern und LINQ oder ähnliche Methoden verwenden, um die Abfragen auszuführen, anstatt die Datenbank zu durchsuchen.

Diese Daten können aus der destilliert werden Öffentliche Domain tz-Datenbank.

Vorteile und Fußnoten dieses Ansatzes:

  1. Es werden keine Regeln in Code eingebettet. Sie können die Offsets für neue Regionen oder Datumsbereiche problemlos anpassen.
  2. Sie müssen nicht jeden Bereich von Daten oder Regionen unterstützen, Sie können sie nach Bedarf hinzufügen.
  3. Regionen müssen nicht direkt geopolitischen Grenzen entsprechen, und um Doppelungen von Zeilen zu vermeiden (z. B. können die meisten US-Bundesstaaten DST auf dieselbe Weise behandeln), können Sie breite RegionClass-Einträge haben, die in einer anderen Tabelle mit traditionellen Listen von verknüpfen Staaten, Länder usw.
  4. Für Situationen wie die USA, in denen sich das Start- und Enddatum der Sommerzeit in den letzten Jahren geändert hat, ist dies ziemlich einfach zu bewältigen.
  5. Da das StartDateTime-Feld auch eine Uhrzeit speichern kann, wird die Standardumschaltzeit von 2:00 Uhr morgens problemlos gehandhabt.
  6. Nicht überall auf der Welt wird eine 1-stündige Sommerzeit verwendet. Dies behandelt diese Fälle leicht.
  7. Die Datentabelle ist plattformübergreifend und könnte ein separates Open-Source-Projekt sein, das von Entwicklern verwendet werden könnte, die nahezu jede Datenbankplattform oder Programmiersprache verwenden.
  8. Dies kann für Offsets verwendet werden, die nichts mit Zeitzonen zu tun haben. Zum Beispiel die 1-Sekunden-Anpassungen, die von Zeit zu Zeit vorgenommen werden, um sich an die Erdrotation anzupassen, historische Anpassungen an und innerhalb des Gregorianischen Kalenders usw.
  9. Da dies in einer Datenbanktabelle enthalten ist, können Standardberichtabfragen usw. die Daten ohne einen Fehler durch einen Geschäftslogikcode nutzen.
  10. Dies gilt auch für Zeitzonenoffsets, wenn Sie es wünschen, und kann sogar spezielle historische Fälle berücksichtigen, in denen eine Region einer anderen Zeitzone zugewiesen ist. Sie benötigen lediglich ein Anfangsdatum, das jeder Region einen Zeitzonen-Offset mit einem minimalen Startdatum zuweist. Dazu müssten Sie für jede Zeitzone mindestens eine Region erstellen, aber Sie könnten interessante Fragen stellen wie: "Was ist der Unterschied in der Ortszeit zwischen Yuma, Arizona und Seattle, Washington am 2. Februar 1989 um 5 Uhr morgens?" (Subtrahiere einfach eine SUM () von der anderen.

Nun, der einzige Nachteil dieses Ansatzes oder irgend ein anderer ist das Konvertierungen von Lokalzeit bis GMT sind nicht perfekt, da jede DST-Änderung einen negativen Offset zur Uhr hat wiederholt sich eine bestimmte Ortszeit. Ich fürchte, es gibt keinen einfachen Weg, damit umzugehen. Das ist einer der Gründe, weshalb lokale Zeiten schlecht sind.


15