Empfehlungen für die Sommerzeit und die Zeitzone

Ich bin der Hoffnung, dass diese Frage und die Antworten darauf die definitive Anleitung, um mit der Sommerzeit, insbesondere auch für den Umgang mit dem change-overs.

Wenn Sie etwas hinzufügen, bitte

Viele Systeme abhängig sind, halten genaue Zeit, das problem ist mit änderungen zu der Zeit aufgrund der Sommerzeit - Bewegung der Uhr vorwärts oder rückwärts.

Zum Beispiel, ein business-Regeln in einer Ordnung der Einnahme-system, das abhängig vom Zeitpunkt der Bestellung - wenn die Uhr änderungen der Regeln vielleicht nicht so klar. Wie sollte der Zeitpunkt der Bestellung gespeichert werden? Es gibt natürlich eine unendliche Anzahl von Szenarien - das ist einfach eine Veranschaulichung.

  • Wie haben Sie befasste sich mit der Sommerzeit-Problem?
  • Welche Annahmen sind Teil Ihrer Lösung? (Suche nach Rahmen hier)

Genauso wichtig, wenn nicht mehr so:

  • Was haben Sie versucht, es hat nicht funktioniert?
  • Warum hat es nicht funktioniert?

Würde mich interessieren, Programmierung, OS, Dauerhaftigkeit der Daten und andere einschlägige Aspekte des Themas.

Allgemeine Antworten sind toll, aber ich würde auch gerne details sehen, vor allem, wenn Sie nur auf einer Plattform.

InformationsquelleAutor der Frage |

  1. 799

    Zusammenfassung der Antworten und andere Daten: (bitte fügen Sie)

    Tun:

    • Wann immer Sie sich beziehen, um einen genauen moment in der Zeit, anhalten Zeit nach einem einheitlichen standard, der davon nicht betroffen ist die Sommerzeit. (GMT und UTC sind gleichwertig mit dieser Hinsicht, aber es ist bevorzugt, die Verwendung des Begriffs UTC. Beachten Sie, dass UTC ist auch bekannt als Zulu oder Z Zeit.)
    • Wenn Sie stattdessen wählen, um fortbestehen einer Zeit, die mit einer lokalen time-Wert, dem lokalen Zeit-offset für diese Besondere Zeit von UTC (dieser Versatz kann sich ändern, während des ganzen Jahres), so dass der Zeitstempel kann später interpretiert werden, eindeutig.
    • In einigen Fällen müssen Sie möglicherweise zu speichern beide wird die UTC-Zeit entspricht der lokalen Zeit. Oft wird dies mit zwei separaten Feldern, aber einige Plattformen unterstützen datetimeoffset Typ speichern können beide in einem einzigen Feld.
    • Bei der Speicherung von Zeitstempeln, als einen numerischen Wert verwenden Unix-Zeit - das ist die Anzahl von ganzen Sekunden, die seit 1970-01-01T00:00:00Z (ohne Schaltsekunden). Wenn Sie eine höhere Genauigkeit, Verwendung von Millisekunden statt. Dieser Wert sollte immer basierend auf UTC-Zeit, ohne Zeit-Zonen-Einstellung.
    • Wenn Sie eventuell zu einem späteren Zeitpunkt ändern müssen, den Zeitstempel, die original time-zone-ID, damit Sie feststellen können, wenn der offset geändert haben kann, vom ursprünglichen Wert aufgezeichnet.
    • Bei der Planung künftiger Veranstaltungen, in der Regel die lokale Zeit wird bevorzugt anstelle von UTC, wie es üblich ist für den offset zu ändern. Siehe Antwortund blog-post.
    • Bei Speicherung der gesamten Daten, wie Geburtstage und Jubiläen, nicht konvertieren auf UTC oder jede andere Zeitzone.
      • Wenn möglich, gespeichert in einem nur-Datum-Datentyp, der nicht eine Zeit des Tages.
      • Wenn so ein Typ nicht verfügbar ist, sollten Sie immer ignorieren die time-of-Tag, als den Wert zu interpretieren. Wenn Sie sich nicht sicher sein, dass die time-of-Tag wird ignoriert, 12:00 Uhr anstatt 00:00 Uhr als ein sicherer Vertreter mal an diesem Tag.
    • Denken Sie daran, dass die Zeitzone offsets sind nicht immer eine ganzzahlige Anzahl von Stunden (zum Beispiel, Indian Standard Time ist UTC+05:30 und Nepal verwendet UTC+05:45).
    • Wenn mit Java, verwenden java.Zeit für Java 8, oder verwenden Sie Joda Time für Java 7 oder niedriger.
    • Wenn mit .NETsollten Sie die Verwendung Noda Zeit.
    • Wenn mit .NETTO ohne Noda Zeit, beachten Sie, dass DateTimeOffset ist oft eine bessere Wahl als DateTime.
    • Wenn die Verwendung von Perl verwenden DateTime.
    • Wenn mit Python, verwenden Sie pytz oder dateutil.
    • Wenn mit Hilfe von JavaScript, verwenden Sie moment.js mit der moment-Zeitzone Erweiterung.
    • Wenn Verwendung von PHP - > 5.2, nutzen Sie die nativen Zeitzonen-Konvertierungen zur Verfügung gestellt von DateTimeund DateTimeZone Klassen. Seien Sie vorsichtig bei der Verwendung von DateTimeZone::listAbbreviations() - siehe Antwort. Halten Sie PHP mit der up-to-date Olson Daten, installieren Sie regelmäßig die timezonedb PECL-Paket; siehe Antwort.
    • Wenn mit C++, verwenden Sie eine Bibliothek verwendet, die einwandfrei implementiert die IANA Zeitzone-Datenbank. Dazu gehören cctzICUund Howard Hinnant "tz" - Bibliothek.
      • Nicht verwenden Steigern für Zeit-zone Konvertierungen. Während die API Ansprüche auf Unterstützung standard IANA (aka "zoneinfo") Bezeichner, es grob ordnet Sie POSIX-style-Daten, ohne Rücksicht auf die reiche Geschichte der änderungen in jeder zone gehabt haben können. (Also, die Datei ist gefallen für die Wartung.)
    • Die meisten business-Regeln verwenden, bürgerlichen Zeit, sondern als UTC oder GMT. Daher planen zu konvertieren UTC-Zeitstempel für eine lokale Zeit-zone vor der Anwendung die Anwendungslogik.
    • Denken Sie daran, dass die Zeitzonen und offsets sind nicht fest und können sich ändern. Zum Beispiel, historisch USA und Großbritannien verwendet, die gleichen Daten zu "spring forward" - und "fall back". Jedoch, in 2007, die UNS verändert, die Daten, die Uhren geändert. Dies bedeutet nun, dass für 48 Wochen des Jahres, der Unterschied zwischen London Zeit und New York beträgt 5 Stunden und 4 Wochen (3 im Frühling, 1 im Herbst) es ist 4 Stunden. Bewusst sein, die Artikel wie dieser in den Berechnungen, die mit mehreren Zonen.
    • Berücksichtigen Sie die Art von Zeit (die tatsächliche Uhrzeit des Ereignisses, broadcast-Zeit, relative Zeit, die geschichtliche Zeit, wiederkehrende Zeit) welche Elemente (Zeitstempel, time zone offset-und Zeit-zone, name), den Sie speichern müssen für eine korrekte retrieval - siehe "Arten von Zeit" in diese Antwort.
    • Halten Sie Ihr Betriebssystem, Datenbank und Anwendung tzdata-Dateien in Synchronisierung, zwischen sich und dem rest der Welt.
    • Auf Servern, festlegen der hardware-Uhren und OS Uhren auf UTC statt einer lokalen Zeitzone.
    • Unabhängig von den vorherigen Punkt, server-side-code, einschließlich web-sites, sollte nie erwarten, dass die lokale Zeitzone des Servers zu sein alles in allem. siehe Antwort.
    • Bevorzugen die Arbeit mit Zeitzonen auf einer Fall-zu-Fall-basis in Ihrer Anwendung code, anstatt Global in config-Datei-Einstellungen oder Standardeinstellungen.
    • Verwenden NTP - Dienste auf allen Servern.
    • Wenn mit FAT32denken Sie daran, dass Zeitstempel gespeichert in lokale Zeit, nicht UTC.
    • Beim Umgang mit wiederkehrenden Ereignissen (wöchentliche TV-show zum Beispiel), denken Sie daran, dass die Zeit änderungen mit DST und verschiedenen Zeitzonen.
    • Immer-Abfrage-Datum-Zeit-Werte als lower-bound-inclusive, upper-bound-exklusive (>=<).

    Nicht:

    • Verwechseln Sie nicht eine "Zeit-zone", wie America/New_York mit einem "time zone offset", wie -05:00. Sie sind zwei verschiedene Dinge. Sehen die Zeitzone tag wiki.
    • Verwenden Sie keine JavaScript - Date Objekt, führen Sie Datum-und Zeitberechnungen in älteren web-Browsern, wie ECMAScript 5.1 und niedriger hat ein Konstruktionsfehlerdie Sommerzeit falsch. (Dies wurde behoben in ECMAScript 6 /2015).
    • Nie das Vertrauen des Auftraggebers Uhr. Es kann sehr wohl falsch sein.
    • Nicht sagen, Menschen zu "immer UTC-überall". Diese weit verbreitete Ratschlag ist kurzsichtig mehrere gültige Szenarios, die weiter oben in diesem Dokument. Verwenden Sie stattdessen den entsprechenden Zeitbezug für die Daten, die Sie arbeiten mit. (Zeitstempel können die UTC-Zeit, aber zukünftige Terminplanung und Termin-nur Werte und sollte nicht).

    Testen:

    • Bei der Prüfung, stellen Sie sicher, testen Sie den Ländern in der westlichen, östlichen, nördlichen und Südlichen Hemisphären (in der Tat in jedem Viertel des Erdballs, also 4 Regionen), beide DST in Bearbeitung und nicht (ergibt 8), und ein Land, das nicht verwenden Sommerzeit (weitere 4 decken alle Regionen, macht 12 insgesamt).
    • Test übergangs des DST, d.h. wenn Sie derzeit in der Sommerzeit, wählen Sie einen Wert aus dem winter.
    • Test "boundary cases", wie die Zeitzone, die UTC+12, mit Sommerzeit, so dass die lokale Zeit UTC+13 im Sommer und sogar Orte, die sind UTC+13 im winter
    • Test alle third-party-Bibliotheken und-Anwendungen und stellen Sie sicher, Sie kümmern sich um das time zone data richtig.
    • Test halb-Stunden-Zeitzonen, mindestens.

    Referenz:

    Anderen:

    • Lobby Ihre Vertreter Ende der Greuel, DST. Wir können immer hoffen...
    • Lobby für Erd Standard Zeit

    InformationsquelleAutor der Antwort

  2. 288

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

    Arten von Zeiten

    Gibt es vier verschiedene Zeiten, die Sie beachten sollten:

    1. Ereignis-Zeit: z.B. die Zeit, wenn eine internationale Sportveranstaltung statt, oder eine Krönung,/Tod/etc. Dies ist abhängig von der Zeitzone des Ereignisses und nicht der viewer.
    2. Fernseh-Zeit: z.B. eine bestimmte TV-show ausgestrahlt wird um 9pm Ortszeit der ganzen Welt. Wichtig, wenn man über die Veröffentlichung der Ergebnisse (z.B. "American Idol") auf Ihre Webseite
    3. Relative Zeit: eg: Diese Frage hat eine offene bounty schließen in 21 Stunden. Dies ist leicht zu display
    4. Wiederkehrende Zeit: zB: Eine TV-show ist jeden Montag um 9pm, auch wenn sich änderungen der Sommerzeit.

    Gibt es auch Historische/alternativen Zeit. Diese sind ärgerlich, weil Sie möglicherweise nicht anzeigen zurück zur Standardzeit. Eg: Julian Termine, Termine laut Mondkalender auf dem Saturn, Der Klingone Kalender.

    Speichern von start - /Ende-Zeitstempel in UTC-gut funktioniert. Für 1, müssen Sie ein Ereignis timezone name + offset gespeichert, zusammen mit dem Ereignis. Für 2, müssen Sie ein lokaler Zeit-identifier gespeichert, der mit jedem Bereich und eine lokale Zeitzone name + offset gespeichert, die für jeden Betrachter (es ist möglich, abzuleiten, das von der IP, wenn Sie in einem crunch). Für 3, - store in UTC-Sekunden und keine Notwendigkeit für die Zeitzonen. 4 ist ein spezieller Fall von 1 oder 2 je nachdem, ob es ein globales oder ein lokales Ereignis, aber Sie müssen auch speichern erstellt am timestamp, also können Sie sagen, wenn eine Zeitzone-definition geändert werden, bevor oder nachdem dieses Ereignis erstellt wurde. Dies ist notwendig, wenn Sie brauchen, um historische Daten.

    Speichern mal

    • Immer speichern die Uhrzeit in UTC
    • Konvertieren, um die lokale Uhrzeit am display (local definiert durch den Benutzer, die Daten zu betrachten)
    • Beim speichern einer Zeitzone, benötigen Sie den Namen, den Zeitstempel und den offset. Dies ist erforderlich, weil die Regierungen ändern sich manchmal die Bedeutungen Ihrer Zeitzonen (z.B.: die US Regierung geändert DST-Terminen), und Ihre Anwendung braucht, um Dinge zu handhaben, anmutig... z.B.: Der genaue Zeitstempel, Wann die Episoden von LOST zeigten sowohl vor und nach der Sommerzeit-Regeln geändert.

    Offsets und Namen

    Beispiel von oben wäre:

    Dem Fußball WM-Spiel
    passiert in Südafrika (UTC+2--SAST)
    im Juli 11, 2010 um 19:00 UTC.

    Mit diesen Informationen, können wir historisch bestimmen, die genaue Zeit, Wann die 2010 WCS finals stattfanden, auch wenn die Südafrikanische Zeitzone definition Veränderungen, und in der Lage sein, um Sie anzuzeigen, um die Zuschauer in Ihre lokale Zeitzone zu der Zeit, wenn Sie die Datenbank Abfragen.

    System Zeit

    Müssen Sie auch halten Sie Ihr Betriebssystem, Datenbank und Anwendung tzdata-Dateien synchron, beide mit einander, und mit dem rest der Welt, und ausgiebig testen, wenn Sie aktualisieren. Es ist nicht ungewöhnlich, dass ein Dritter-app, die Sie abhängen wollte nicht mit einer TZ-richtig ändern.

    Stellen Sie sicher, dass die hardware-Uhr auf UTC eingestellt ist, und wenn Sie mit Servern rund um die Welt, machen Sie sicher, dass Ihre Betriebssysteme sind so konfiguriert, UTC-Zeit als gut. Dies wird offensichtlich, wenn Sie brauchen, um zu kopieren stündlich gedreht apache-log-Dateien von Servern in mehreren Zeitzonen. Sortieren Sie nach Dateinamen funktioniert nur, wenn alle Dateien benannt sind, mit den gleichen Zeitzone. Es bedeutet auch, dass Sie nicht zu tun haben, Datum, Mathe in den Kopf, wenn du ssh von einem Feld zum anderen und vergleichen müssen Zeitstempel.

    Auch, ntpd auf alle Boxen.

    Kunden

    Nie das Vertrauen der timestamp erhalten Sie von einer client-Maschine gültig sind. Beispielsweise das Datum: - HTTP-Header oder javascript Date.getTime() nennen. Diese sind in Ordnung, wenn verwendet, als undurchsichtig-IDS, oder, wenn dabei date math, die während einer einzigen Sitzung auf dem gleichen client, aber versuchen Sie nicht, cross-Referenz diese Werte mit etwas, das Sie auf dem server haben. Ihre Kunden nicht ausführen, NTP, und nicht unbedingt eine funktionierende Batterie für den BIOS-Uhr.

    Trivia

    Schließlich die Regierungen manchmal sehr seltsame Dinge:

    Standard-Zeit in den Niederlanden war
    genau 19 Minuten und 32.13 Sekunden
    vor der UTC, die per Gesetz 1909-05-01
    durch 1937-06-30. Diese Zeitzone
    nicht exakt dargestellt werden mit
    das HH:MM format.

    Ok, ich denke ich bin fertig.

    InformationsquelleAutor der Antwort

  3. 81

    Dies ist ein wichtiger und überraschend hartes Problem. Die Wahrheit ist, dass es keine völlig befriedigend ist standard für die Persistenz der Zeit. Zum Beispiel, den SQL-standard und das ISO-format (ISO 8601), sind deutlich genug.

    Aus der konzeptionellen Sicht, wird man in der Regel befasst sich mit zwei Arten von Zeit-Datum-Daten, und es ist bequemer, Sie zu unterscheiden (die oben genannten Normen nicht) : "physikalischen Zeit" und "bürgerlichen Zeit".

    Einer "physischen" Augenblick der Zeit ist ein Punkt in der kontinuierlichen universal-timeline, in der Physik beschäftigen sich mit (ohne Berücksichtigung der Relativität, natürlich). Dieses Konzept adäquat codiert, beibehalten, in UTC, zum Beispiel (wenn Sie ignorieren können Schaltsekunden).

    Einer "zivilen" Zeit ist ein datetime-Spezifikation folgt, dass die bürgerlichen Normen: ein Punkt der mal hier ist vollständig spezifiziert durch einen Satz von datetime-Felder (Y,M,D,H,MM,S,FS) plus TZ (timezone specification) (auch ein "Kalender", eigentlich; aber nehmen wir an, wir beschränken die Diskussion auf den Gregorianischen Kalender). Eine Zeitzone und einen Kalender gemeinsam zugelassen sind (in-Prinzip), aus der die Zuordnung einer Darstellung in eine andere. Aber die bürgerlichen und physischen time instants sind grundsätzlich verschiedene Arten von Größen, und Sie sollten gehalten werden konzeptionell getrennt und unterschiedlich behandelt (eine Analogie: arrays von bytes und Zeichenketten (strings).

    Die Frage ist verwirrend, weil wir davon sprechen, dass diese Arten von Ereignissen austauschbar, weil die Zivil-Zeiten sind abhängig von der politischen Veränderungen. Das problem (und die Notwendigkeit, diese zu unterscheiden-Konzepte) wird umso deutlicher, für Ereignisse in der Zukunft. Beispiel (aus meiner Diskussion hier.

    Johannes berichtet in seinem Kalender eine Erinnerung für ein Ereignis bei datetime
    2019-Jul-27, 10:30:00TZ=Chile/Santiago (mit offset /GMT-4,
    daher entspricht UTC 2019-Jul-27 14:30:00). Aber irgendwann
    in die Zukunft des Landes entscheidet, ändern Sie die TZ-offset zur GMT-5.

    Nun, wenn der Tag kommt,... sollte, die Erinnerung auslösen, um

    A) 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 ?

    Gibt es keine richtige Antwort, es sei denn, man weiß, was John konzeptionell gemeint
    wenn er erzählte der Kalender, "Bitte rufen Sie mich an 2019-Jul-27, 10:30:00
    TZ=Chile/Santiago    ".

    Wollte er, dass eine "Zivil-date-time" ("wenn die Uhren in meiner Stadt erzählen
    10:30")? In diesem Fall A) die richtige Antwort.

    Oder meinte er einen "physischen instant of time", ein Punkt in der continuus
    Linie der Zeit unseres Universums, sagen wir, "wenn die nächste Sonnenfinsternis
    passiert". In diesem Fall die Antwort B) ist richtig.

    Ein paar Datum/Zeit-APIs erhalten diese Unterscheidung Recht: unter Ihnen, Jodatimedie das Fundament der nächsten (Dritten!) Java DateTime-API (JSR 310).

    InformationsquelleAutor der Antwort

  4. 53

    Machen klare architektonische Trennung der Anliegen, genau zu wissen, welches tier interagiert mit dem Benutzer, und ändern Datum-Zeit-zur/von der kanonischen Darstellung (UTC). Nicht-UTC-Datum und-Zeit ist die Präsentation (folgt die Benutzer lokale Zeitzone), UTC-Zeit-Modell (bleibt einzigartig für die back-end-und mid-tiers).

    Auch, entscheiden, was Ihre eigentliche Publikum, was Sie nicht haben, um zu dienen und wo ziehst du die Linie. Don ' T touch exotische Kalender, es sei denn, Sie haben tatsächlich wichtige Kunden dort und dann sollten Sie separate Benutzer-zugewandten-server(s), die nur für diese region.

    Wenn Sie erwerben und pflegen user ' s location, location für systematische Datum-Uhrzeit-Konvertierung (sagen .Netzkultur oder einer SQL-Tabelle), aber Sie stellen eine Möglichkeit für end-Benutzer zu wählen, überschreibt, wenn Datum und Uhrzeit ist entscheidend für Ihre Benutzer.

    Wenn es historische audit-Pflichten beteiligt (wie sagen genau dann, wenn Jo in der AZ eine Rechnung bezahlt 2 Jahre alt im September) dann halten die beiden UTC-Zeit und lokaler Zeit für den Datensatz (Ihre conversion-Tabellen ändern sich im Laufe der Zeit).

    Die Zeitspanne definieren, die die referenzielle Zeitzone für Daten, die in der Masse - wie Dateien, web services etc. Sagen Ost-Küste Unternehmen Rechenzentrum in CA - Sie stellen müssen, und wissen, was Sie verwenden, wie ein standard-statt anzunehmen, dass der eine oder andere.

    Nicht trauen, Zeitzonen-offsets eingebettet in die textliche Darstellung des Datums -, Zeit-und nicht akzeptieren, zu analysieren und Ihnen zu Folgen. Anstatt immer zu verlangen, dass die Zeitzone und/oder Verweis zone müssen explizit definiert werden. Sie können leicht erhalten Zeit mit PST-offset, aber die Zeit ist eigentlich EST, da der client die Referenz-Zeit und Unterlagen waren nur exportiert werden an einen server in PST.

    InformationsquelleAutor der Antwort

  5. 38

    Müssen Sie wissen, über die Olson -tz-Datenbankdas von ,ftp://elsie.nci.nih.gov/pub http://iana.org/time-zones/. Es aktualisiert wird mehrere Male pro Jahr zu bewältigen, die oft in letzter minute änderungen, wenn (und ob) die Umschaltung zwischen winter und Sommer (standard-und Sommerzeit) die Zeit in verschiedenen Ländern auf der ganzen Welt. Im Jahr 2009, der Letzte release war 2009s; im Jahr 2010, es war 2010n; in 2011, es war 2011n; Ende Mai 2012 wurde die Veröffentlichung 2012c. Beachten Sie, dass es einen Satz von code, um die Daten zu verwalten und dem tatsächlichen Zeit-zone eigentlichen Daten in zwei getrennten Archiven (tzcode20xxy.tar.gz und tzdata20xxy.tar.gz). Code und Daten sind in der public domain.

    Dies ist die Quelle der Zeitzone Namen wie America/Los_Angeles (und Synonyme wie US/Pacific).

    Wenn Sie brauchen, um zu verfolgen die verschiedenen Zonen, dann müssen Sie die Olson-Datenbank. Wie andere hingewiesen haben, Sie wollen auch die Daten gespeichert, die in einem festen format — UTC ist in der Regel der gewählt wurde — zusammen mit einem Datensatz von der Zeitzone, in der die Daten generiert wurden. Möchten Sie vielleicht zu unterscheiden zwischen der offset von UTC in die Zeit und die Zeitzone den Namen; das kann einen Unterschied machen später. Auch die Kenntnis, dass es derzeit 2010-03-28T23:47:00-07:00 (US/Pacific), kann oder kann nicht helfen Sie mit, den Wert zu interpretieren 2010-11-15T12:30 — das ist vermutlich angegeben in PST (Pacific Standard Time) statt PDT (Pacific Daylight Saving Time).

    Den standard-C-library-Schnittstellen sind nicht schrecklich hilfreich mit dieser Art von Sachen.

    Den Olson-Daten verschoben hat, zum Teil, weil Ein D Olson Ruhestand bald, und teilweise, weil es war ein (inzwischen entlassen) Klage gegen die Betreiber wegen Verletzung des Urheberrechts. Die Zeitzone der Datenbank ist es nun gelungen, unter der Schirmherrschaft von IANAdie Internet Assigned Numbers Authority), und es gibt einen link auf der ersten Seite, um 'Time Zone Database'. Die Diskussions-Mailingliste ist jetzt [email protected]; die Bekanntmachung der Liste ist [email protected].

    InformationsquelleAutor der Antwort

  6. 24

    Im Allgemeinen, gehören die local time offset (einschließlich DST-offset) in gespeicherten Zeitstempel: UTC allein ist nicht genug, wenn Sie später wollen, um den Zeitstempel in seine ursprüngliche Zeitzone (und die DST-Einstellung).

    Beachten Sie, dass der offset ist nicht immer eine ganzzahlige Anzahl von Stunden (z.B. Indian Standard Time ist UTC+05:30).

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

    InformationsquelleAutor der Antwort

  7. 22

    Überqueren die Grenze des "computer-Zeit" und "Zeit" ist ein Alptraum. Das wichtigste ist, dass es keine Art von standard für die Regeln für Zeitzonen-und Sommerzeit-Zeit. Die Länder sind frei, zu ändern Ihrer Zeitzone und der Sommerzeit-Regeln zu jeder Zeit, und Sie tun.

    Einige Länder wie z.B. Israel, Brasilien, entscheiden jedes Jahr, wenn Ihre Sommerzeit-Zeiten, so ist es unmöglich, im Voraus zu wissen, Wann (wenn) die Sommerzeit in Kraft. Andere haben Feste(ish) Regeln, wenn DST in Kraft ist. Andere Länder verwenden Sie keine Sommerzeit wie alle.

    Zeitzonen nicht zur vollen Stunde auf Unterschiede von GMT. Nepal ist +5.45. Es gibt sogar Zeitzonen, +13. Das bedeutet, dass:

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

    sind alle die gleiche Zeit noch 3 verschiedene Tage!

    Gibt es auch keine klare Norm auf die Abkürzungen für die Zeitzonen, und wie Sie sich ändern, wenn in der Sommerzeit, so dass Sie am Ende mit Dingen wie diesen:

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

    Der beste Rat ist zu bleiben Weg von lokalen-mal so viel wie möglich und halten Sie sich an UTC, wo Sie können. Nur konvertieren, um die lokale Uhrzeit an der letzten möglichen moment.

    Beim testen stellen Sie sicher, testen Sie die Länder in die westlichen und östlichen Hemisphären, beide DST in Bearbeitung und nicht und ein Land, das nicht verwenden Sommerzeit (6 insgesamt).

    InformationsquelleAutor der Antwort

  8. 18

    Für PHP:

    Den DateTimeZone-Klasse in PHP - > 5.2 basieren bereits auf die Olson-DB, die andere erwähnen, so, wenn Sie tun, Zeitzone Konvertierungen in PHP und nicht in der DB, Sie sind befreit von der Arbeit mit (schwer zu verstehen) Olson-Dateien.

    Aber PHP ist nicht so Häufig aktualisiert, wie die Olson-DB, also nur mit PHPs Zeitzone Konvertierungen können lassen Sie mit veralteten DST-Informationen und Einfluss auf die Richtigkeit Ihrer Daten. Dies ist zwar nicht zu erwarten, dass Häufig vorkommen, kann es passieren, und wird passieren, wenn Sie eine große Basis von Anwendern weltweit.

    Zur Bewältigung der oben genannten Problem, verwenden Sie die timezonedb pecl-Paketdass die Funktion zum aktualisieren der PHP-timezone-Daten. Installieren Sie dieses Paket, so oft es aktualisiert wird. (Ich bin mir nicht sicher, ob diese Pakete updates Folgen Olson updates genau, aber es scheint aktualisiert zu werden, in einer Frequenz, die mindestens sehr nahe zu Olson-updates.)

    InformationsquelleAutor der Antwort

  9. 15

    Wenn Ihr design aufnehmen können, vermeiden, Konvertierung von Ortszeit alle zusammen!

    Kenne ich einige, das klingt vielleicht verrückt, aber denke über UX: Benutzer-Prozess in der Nähe, relative Termine (heute, gestern, nächsten Montag) schneller als absoluten Daten (2010.09.17, Freitag Sept 17) auf Blick. Und wenn Sie darüber nachdenken mehr, die Genauigkeit der Zeitzonen (und Sommerzeit) wird wichtiger, je näher das Datum now()so dass, wenn Sie können express-Termine/datetimes in einem relativen format +/- 1 oder 2 Wochen, der rest der Daten können Sie UTC-Zeit und es wird nicht egal, zu viel für 95% der Nutzer.

    Diese Weise können Sie speichern alle Daten in UTC-Zeit und das tun die relative Vergleiche in UTC und nur zeigen, die Benutzer UTC Termine außerhalb Ihrer Relativen Datums-Schwelle.

    Diese können auch auf Benutzereingaben zu (aber in der Regel in eingeschränkter Weise). Auswahl aus einem drop-down, nur hat { Gestern, Heute, Morgen, Nächsten Montag, am Kommenden Donnerstag } ist so viel einfacher und leichter für den Benutzer als ein Datum-picker. Date pickers sind einige der am meisten Schmerz-induzierende Komponenten ausfüllen. Natürlich funktioniert dies nicht für alle Fälle, aber Sie können sehen, dass es dauert nur ein wenig cleveres design machen es sehr mächtig.

    InformationsquelleAutor der Antwort

  10. 15

    Während ich habe nicht versucht es, einen Ansatz zur Zeit-zone Anpassungen fände ich überzeugend wäre wie folgt:

    1. Speichern alles in UTC.

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

    In der Tabelle, speichern Sie eine Liste von Datums-und Zeitangaben wenn der lokalen Zeit geändert, und um wie viel. Die Anzahl der Regionen in der Tabelle und die Anzahl der Termine hängt davon ab, welcher Bereich der Daten und der Gebiete der Welt, die Sie unterstützen müssen. Dies so vorstellen, als wenn es ein "historisches" Datum, auch wenn die Termine umfassen sollte, die Zukunft auf einige praktische Grenze.

    Wenn Sie brauchen, um zu berechnen die lokale Zeit von der UTC-Zeit, genau dies zu tun:

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

    Möchten Sie vielleicht, um cache dieser Tabelle in Ihre app und verwenden Sie LINQ oder ähnliche Mittel zu tun, die Abfragen als schlagen der Datenbank.

    Diese Daten können destilliert werden von der public-domain-tz-Datenbank.

    Vorteile und Fußnoten zu diesem Ansatz:

    1. Keine Regeln gebacken in code, können Sie die offsets für neue Regionen oder Zeiträume leicht.
    2. Sie nicht haben, um Unterstützung jeder Reihe von Terminen oder Regionen, können Sie Sie hinzufügen, wie gebraucht.
    3. Regionen nicht entsprechen direkt den geopolitischen Grenzen, und Doppelarbeit zu vermeiden Zeilen (zum Beispiel, die meisten Staaten in den USA behandeln Sommerzeit die gleiche Weise), Sie können haben Breite RegionClass Einträge, die link in eine andere Tabelle zu eher klassischen Listen von Staaten, Ländern, usw.
    4. Für Situationen wie den USA, wo die start-und Enddatum der Sommerzeit hat sich in den letzten paar Jahren, das ist ziemlich einfach zu behandeln.
    5. Da die Parameter startdatetime Feld speichern kann, die Zeit als auch die 2:00 UHR standard-change-over-time ist problemlos behandelt werden.
    6. Nicht überall in der Welt verwendet ein 1-Stunden-DST. Diese behandelt jene Fälle leicht.
    7. Die Daten-Tabelle ist cross-Plattform und könnte eine separate open-source-Projekt, das verwendet werden könnte, die von Entwicklern, die fast jede Datenbank-Plattform oder Programmiersprache.
    8. Dies kann verwendet werden, für die offsets, die haben nichts zu tun mit der Zeit-Zonen. Zum Beispiel die 1-Sekunden-Einstellungen, das geschehen von Zeit zu Zeit anpassen, denn die rotation der Erde, historische Anpassungen und innerhalb der gregorianische Kalender, etc.
    9. Da diese in einer Datenbank-Tabelle, standard-report-Abfragen, etc. können die Daten nutzen, ohne eine Reise durch die business-Logik-code.
    10. Diese Griffe Zeitzone offsets als gut, wenn Sie es wollen, und können sogar für Besondere historische Fälle, in denen eine region zugeordnet ist, zu einer anderen Zeitzone. Alles, was Sie brauchen, ist ein erstes date, weist Zeitzonen-offset für jede region mit einer minimalen start-Datum. Dies würde erfordern, erstellen Sie zumindest eine region, die für jeden Zeit-zone, aber die erlauben würde, Sie zu Fragen, interessante Fragen wie: "Was ist der Unterschied zwischen der lokalen Zeit zwischen Yuma, Arizona und Seattle, Washington am 2. Februar 1989 um 5:00 Uhr?" (Nur subtrahieren einer SUMME() aus dem anderen).

    Nun, der einzige Nachteil dieses Ansatzes oder andere ist, dass Konvertierungen von lokalen Zeit zur GMT sind nicht perfekt, da jeder Zeitumstellung, die hat einen negativen offset auf die Uhr wiederholt einer lokalen Zeit. Kein einfacher Weg, damit umzugehen, ich fürchte, das ist ein Grund, warum die Speicherung von lokalen Zeiten ist die schlechte Nachricht in den ersten Platz.

    InformationsquelleAutor der Antwort

  11. 12

    Ich habe trifft dies auf zwei Arten von Systemen, die "shift-planning-Systeme (z.B. Fabrikarbeiter)" und "gas hängen-management-Systeme)...

    23 und 25 Stunden langen Tagen einen Schmerz zu bewältigen, so sind 8 STD Schichten, nehmen 7hr oder 9hr. Das problem ist, Sie werden feststellen, dass jeder Kunden oder sogar Abteilung des Kunden haben verschiedene Regeln, die Sie erstellt haben (oft ohne es zu dokumentieren), was Sie tun, in diesen besonderen Fällen.

    Einige Fragen werden am besten nicht gefragt, der den Kunden erst, nachdem Sie bezahlt haben für Ihre "off-the-shelf" - software. Es ist sehr selten, dass ein Kunde, der denkt, dass über diese Art von Problem vorne, wenn der Kauf einer software.

    Ich denke, in allen Fällen sollten Sie Ihre Rekord-Zeit in UTC und Konvertierung zu/von der Ortszeit vor dem speichern von Datum/Uhrzeit. Jedoch auch wissen, welche nehmen einem die Zeit gegeben ist, lässt sich schwer mit der Sommerzeit-und Zeitzonen.

    InformationsquelleAutor der Antwort

  12. 10

    Für das web, die Regeln sind nicht so kompliziert...

    • Server-Seite, verwenden Sie UTC
    • Client-Seite verwenden Olson
      • Grund: UTC-offsets sind nicht die Sommerzeit-safe (z.B. New York EST (UTC - 5 Stunden) Teil des Jahres, EDT (UTC - 4 Stunden), der rest des Jahres).
      • Für die client-Seite Zeit-zone, Entschlossenheit, haben Sie zwei Möglichkeiten:

    Der rest ist nur UTC/lokale Konvertierung mithilfe Ihrer server-datetime-Bibliotheken. Gut zu gehen...

    InformationsquelleAutor der Antwort

  13. 10

    Ich hatte vor kurzem ein problem in einer web-Anwendung, wo auf eine Ajax-post-zurück in der datetime-kommen wir zurück zu meinem server-side-code war anders als die datetime serviert.

    Ist es sehr wahrscheinlich, hatte zu tun mit meinem JavaScript-code auf dem client, der die Datum für die Buchung zurück an den client als string übergeben, da JavaScript wurde die Einstellung für die Zeitzone und die Sommerzeit, und in einigen Browsern wird die Berechnung für den Zeitpunkt gilt die Sommerzeit schien anders zu sein als in anderen.

    Am Ende entschied ich mich zu entfernen von Datum und Zeit Berechnungen auf dem client vollständig, und zurück gebucht auf meine server auf einem integer-Schlüssel, der bekam dann übersetzt, um Datum und Zeit auf dem server zu ermöglichen, sich für konsequente Umsetzungen.

    Mein learning daraus:
    Verwenden Sie keine JavaScript-Datum-und Zeit-Berechnungen in web-Anwendungen, es sei denn Sie ABSOLUT müssen.

    InformationsquelleAutor der Antwort

  14. 10

    Wenn es um Anwendungen auf einem servereinschließlich web-Seiten und andere back-end-services, die Einstellung der Zeitzone des Servers ignoriert werden sollten von der Anwendung.

    Die gemeinsame Beratung ist, um die server-Zeitzone auf UTC. Dies ist in der Tat eine gute best-practice, aber es ist da, wie ein band-Beihilfen für Anwendungen, die nicht nach anderen best practices. Zum Beispiel, ein Dienst könnte das schreiben auf log-Dateien mit den lokalen Zeitstempel anstelle von UTC-basierten Zeitstempel, wodurch Unklarheiten während der Sommerzeit fall-back-übergang. Einstellung der server-Zeitzone auf UTC zu beheben dass Anwendung. Aber die wirkliche Lösung wäre für die Anwendung, um log-UTC verwendet, um mit zu beginnen.

    Server-side-code, einschließlich web-sites, sollte nie erwarten, dass die lokale Zeitzone des Servers zu sein alles in allem.

    In einigen Sprachen, die lokale Zeitzone krieche in den code der Anwendung. Zum Beispiel, die DateTime.ToUniversalTime Methode .NET konvertieren von der lokalen Zeitzone zu UTC und die DateTime.Now - Eigenschaft gibt die aktuelle Uhrzeit in der örtlichen Zeitzone. Auch die Date Konstruktor in JavaScript verwendet der computer die lokale Zeitzone. Es gibt viele weitere Beispiele wie dieses. Es ist wichtig, zu üben defensive Programmierung, die Vermeidung von code, der den computer verwendet, die lokale Zeitzone einstellen.

    Reserve mit der lokalen Zeitzone für client-side code wie desktop-Anwendungen, mobile Anwendungen und client-side JavaScript.

    InformationsquelleAutor der Antwort

  15. 9

    Halten Ihren Server auf UTC eingestellt ist, und stellen Sie sicher, dass Sie alle so konfiguriert sind, dass ntp oder den Gegenwert.

    UTC vermeidet die Zeitumstellung Probleme, und out-of-sync-Server kann zu unvorhersehbaren Ergebnissen führen, die eine Weile dauern zu diagnostizieren.

    InformationsquelleAutor der Antwort

  16. 8

    Seien Sie vorsichtig beim Umgang mit Zeitstempel gespeichert, die im FAT32-Dateisystem - es wird immer beibehalten, in der lokalen Zeit-Koordinaten (die DST - siehe msdn-Artikel). In Brand geraten.

    InformationsquelleAutor der Antwort

  17. 6

    Eine andere Sache, stellen Sie sicher, dass die Server die up-to-date daylight savings patch angewendet.

    Hatten wir eine situation im letzten Jahr, wo unsere Zeiten waren durchweg von einer Stunde für einen Zeitraum von drei Wochen für Nord-amerikanische Nutzer, obwohl wir noch eine UTC-basierten system.

    Es stellt sich heraus, am Ende war es der Server. Sie brauchte nur ein up-to-date-patch angewendet (Windows Server 2003).

    InformationsquelleAutor der Antwort

  18. 5

    PHP DateTimeZone::listAbbreviations() Ausgang

    Diese PHP-Methode gibt ein assoziatives array mit einigen "großen" Zeitzonen (wie CEST), die auf Ihre eigenen enthalten weitere spezifische "geografische" Zeitzonen (Europa/Amsterdam).

    Wenn Sie diese Zeitzonen und deren offset - /Sommerzeit-Informationen, es ist extrem wichtig, um zu erkennen:

    Wie es scheint alle anderen offset/DST-Konfigurationen (einschließlich historischer Konfigurationen) jeder Zeitzone enthalten sind!

    Beispielsweise, Europe/Amsterdam finden sechs mal in der Ausgabe von dieser Funktion. Zwei vorkommen (offset 1172/4772) sind für die Amsterdam-Zeit bis 1937; zwei (1200/4800) sind für die Zeit, die verwendet wurde, zwischen 1937 und 1940, und zwei (3600/4800) sind für die Zeit, die seit 1940.

    Daher verlassen Sie sich nicht auf die offset - /DST-Informationen, die von dieser Funktion zurückgegeben als die derzeit korrekte/in Verwendung!

    Wenn Sie wissen möchten der aktuelle offset - /Sommerzeit einer bestimmten Zeitzone, die Sie haben zu tun so etwas wie dieses:

    <?php
$now = new DateTime(null, new DateTimeZone('Europe/Amsterdam'));
echo $now->getOffset();
?>

    InformationsquelleAutor der Antwort

  19. 4

    Wenn Sie geschehen, zu pflegen, Datenbank-Systeme, auf denen mit DST aktiv ist, prüfen Sie genau, ob Sie heruntergefahren werden müssen, während der übergang in den Herbst. Mandy DBS (oder andere Systeme) nicht wie an der gleichen Stelle in der (lokalen) Zeit zweimal, das ist genau das, was passiert, wenn Sie drehen Sie die Uhr zurück im Herbst. SAP hat das Problem gelöst mit einer (IMHO wirklich ordentlich) Abhilfe - statt drehen die Uhr zurück, Sie lassen einfach die interne Uhr laufen auf die Hälfte der üblichen Geschwindigkeit für zwei Stunden...

    InformationsquelleAutor der Antwort

  20. 4

    Geschäftsregeln sollten auch immer auf in der bürgerlichen Zeit (es sei denn, es gibt Gesetze, die etwas anderes sagt). Werden Sie sich bewusst, dass in der bürgerlichen Zeit ist ein Chaos, aber es ist, was Leute verwenden, so ist es, was wichtig ist.

    Intern halten Zeitstempel in so etwas wie civil-Zeit-Sekunden-aus-Epoche. Die Epoche spielt keine Rolle, vor allem (ich zugunsten der Unix-Epoche), aber es macht Dinge einfacher, als die alternative. Behaupten, dass Sprung-Sekunden nicht existieren, es sei denn, Sie etwas tun, das wirklich Bedürfnisse (z.B., satellite tracking). Die Zuordnung zwischen Zeitstempel und angezeigte Zeit ist der einzige Punkt, wo Sommerzeit Regeln angewandt werden; die Regeln ändern sich Häufig (auf globaler Ebene, mehrmals im Jahr; die Schuld der Politiker), so sollten Sie sicherstellen, dass Sie nicht hart-code, der das mapping. Olson ist TZ-Datenbank ist von unschätzbarem Wert.

    InformationsquelleAutor der Antwort

  21. 3

    Verwenden Sie die .NET framework?
    Wenn ja, lassen Sie mich Ihnen den DateTimeOffset Art, Hinzugefügt .NET 3.5.

    Diese Struktur enthält sowohl eine DateTime und einem Offset (TimeSpan), gibt die Differenz zwischen der DateTimeOffset Beispiel Datum und Uhrzeit und die UTC (Universal Time Coordinated).

    • Den DateTimeOffset.Now statische Methode zurück DateTimeOffset
      Beispiel aus der aktuellen (lokalen) Zeit, und die lokale offset
      (wie im Betriebssystem definierte, regional-info).

    • Den DateTimeOffset.UtcNow statische Methode gibt eine
      DateTimeOffset Beispiel aus der aktuellen Zeit in UTC (als
      wenn Sie wurden in Greenwich).

    Andere nützliche Arten sind die TimeZone und TimeZoneInfo Klassen.

    InformationsquelleAutor der Antwort

  22. 3

    Für diejenigen, die kämpfen mit diesem auf .NETsehen, ob mit DateTimeOffset - und/oder TimeZoneInfo sind, lohnt sich.

    Wenn Sie verwenden möchten IANA/Olson-Zeitzonenoder finden Sie die eingebauten Typen sind nicht ausreichend für Ihre Bedürfnisse, check-out Noda Zeitdie bietet eine viel intelligentere Datum-und Zeit-API .NET.

    InformationsquelleAutor der Antwort

  23. 2

    Wollte nur darauf hinweisen, zwei Dinge, die scheinen falsch oder zumindest verwirrend:

    Immer bestehen Zeit nach einem einheitlichen standard, der nicht
    betroffen durch die Sommerzeit. GMT und UTC wurden erwähnt
    unterschiedliche Menschen, obwohl UTC zu sein scheint, am häufigsten genannt.

    Für (fast) alle praktischen computing Zwecke UTC ist, in der Tat, GMT. Es sei denn, Sie sehen einen Zeitstempel mit einer Sekundenbruchteilen, Sie beschäftigen sich mit der GMT, die macht diese Unterscheidung überflüssig.

    Gehören die local time offset (einschließlich DST-offset), wenn
    die Speicherung von Zeitstempeln.

    Timestamp ist immer vertreten, in GMT und hat somit keinen offset.

    InformationsquelleAutor der Antwort

  24. 2

    Hier meine Erfahrung:-

    (Erfordert keine Drittanbieter-Bibliothek)

    • Auf server-Seite, speichern von Zeiten im UTC-format, so dass alle Datum/Zeit-Werte in der Datenbank werden in einer einzigen standard-unabhängig vom Standort der Benutzer, die Server, Zeitzonen oder Sommerzeit.
    • Auf die UI-Ebene oder in E-Mails, um Benutzer, die Sie benötigen, um zu zeigen, mal nach user. Für diese Angelegenheit, Sie müssen Benutzer die Zeitzone versetzt, so dass Sie können fügen Sie diesen Versatz, um Ihre Datenbank UTC-Wert, die in Ihrer lokalen Zeit. Sie können entweder Benutzer-Zeitzone-offset, wenn Sie oben unterzeichnen, oder Sie können auto-Erkennung in web-und mobile-Plattformen. Für websites, die JavaScript-Funktion getTimezoneOffset () - Methode ist eine standard seit version 1.0 und mit allen Browsern kompatibel. (Ref: http://www.w3schools.com/jsref/jsref_getTimezoneOffset.asp)

    InformationsquelleAutor der Antwort

  25. 2

    Tom Scott ' s video über Zeitzonen auf YouTube auf die Computerphile Kanal hat auch eine nette und unterhaltsame Beschreibung des Themas.
    Beispiele:

    • Samoa (eine Insel im Pazifischen Ozean) eine Verschiebung der Zeitzone Vorlauf von 24 Stunden, um den Handel einfacher mit Australien und Neuseeland,
    • West Bankwobei 2 Populationen von Menschen sind folgende verschiedenen Zeitzonen,
    • 18th century änderungen aus dem Julian Kalender Gregorianischen
      Kalender (was im 20 Jahrhundert in Russland).

    InformationsquelleAutor der Antwort

  26. 1

    Eigentlich kernel32.dll nicht exportieren SystemTimeToTzSpecificLocation. Allerdings wird der export der folgenden zwei: SystemTimeToTzSpecificLocalTime und TzSpecificLocalTimeToSystemTime...

    InformationsquelleAutor der Antwort

  27. 1

    Nur ein Beispiel, um zu beweisen, dass der Umgang mit Zeit ist die Riesen Sauerei beschrieben, und dass Sie nie selbstzufrieden sein. In mehreren spots auf dieser Seite Sprung-Sekunden ignoriert worden.

    Einigen Jahren die Android-Betriebssystem verwendet GPS Satelliten, um einen UTC-Zeit verweisen, aber ignoriert die Tatsache, dass GPS-Satelliten nicht verwenden, Sprung-Sekunden. Niemand bemerkt, bis es zu Verwirrung auf Silvester, wenn das Apple-Handy-Nutzer und Android-Handy-Benutzer haben Ihren count-downs etwa 15 Sekunden auseinander.

    Ich denke, es wurde inzwischen behoben, aber man kann nie wissen, wenn diese 'Kleinigkeiten' kommen zurück, um dich heimzusuchen.

    InformationsquelleAutor der Antwort

  28. 0

    Verlassen Sie sich niemals nur auf Konstruktoren wie 

     new DateTime(int year, int month, int day, int hour, int minute, TimeZone timezone)

    Können Sie exceptions werfen, wenn ein bestimmtes Datum gibt es nicht Zeit aufgrund der Sommerzeit. Stattdessen bauen Sie Ihre eigenen Methoden für die Erstellung solcher Termine. In Ihnen, alle Ausnahmen abzufangen, die auftreten, aufgrund von Sommerzeit und stellen Sie die Zeit, die benötigt wird, die mit dem übergang offset. Sommerzeit auftreten, die zu unterschiedlichen Zeitpunkten und zu unterschiedlichen Zeiten (auch um Mitternacht für Brasilien) nach der Zeitzone.

    InformationsquelleAutor der Antwort

  29. 0
    • Nie, nie speichern, lokale Zeit, ohne seine UTC-offset (oder einen Verweis auf die Zeitzone)—Beispiele, wie man es nicht machen gehören FAT32 und struct tm in C. 1
    • Verstehen, dass eine Zeitzone ist eine Kombination von
      • eine Reihe von UTC-offsets (z.B. +0100 im winter +0200 Sommer)
      • Regeln für, wenn die Umstellung passiert (die möglicherweise im Laufe der Zeit ändern: beispielsweise in den 1990er Jahren die EU-harmonisiert den Wechsel als am letzten Sonntag im März und Oktober um 02:00 standard Zeit/03:00 Uhr Sommerzeit; früher Unterschied sich zwischen den Mitgliedstaaten).

    1 Einige Implementierungen von struct tm lagern Sie den UTC-offset, das hat aber nicht in die standard.

    InformationsquelleAutor der Antwort

  30. -4

    Im Umgang mit Datenbanken (insbesondere MySQLaber dies gilt für die meisten Datenbanken), fand ich es schwer zu lagern UTC.

    • Datenbanken arbeiten in der Regel mit server-datetime-standardmäßig (das heißt, CURRENT_TIMESTAMP).
    • Sie möglicherweise nicht in der Lage, ändern Sie die server-Zeitzone.
    • Auch wenn Sie sind in der Lage, ändern Sie die Zeitzone, die Sie haben können third-party-code, der erwartet, dass server-Zeitzone zu lokal.

    Fand ich es einfacher zu speichern nur server-datetime in der Datenbank, dann lassen Sie die Datenbank konvertieren, die gespeicherte datetime zurück zu UTC (UNIX_TIMESTAMP()) in SQL-Anweisungen. Danach können Sie die datetime UTC in Ihrem code.

    Wenn Sie haben 100% Kontrolle über den server und alle code, ist es wahrscheinlich besser zu wechseln server-Zeitzone auf UTC.

    InformationsquelleAutor der Antwort

Schreibe einen Kommentar