Vor kurzem arbeitete ich an der Aufgabe, der von meinem Team verwalteten JS-Kalenderbibliothek Zeitzonen hinzuzufügen. Ich war mir der nutzlosen Zeitzonenunterstützung in JavaScript bewusst, hoffte jedoch, dass das Abstrahieren vorhandener Datenobjekte die Lösung der meisten Schwierigkeiten erleichtern würde.
Meine Träume gingen jedoch zu Staub. Als ich mich mit der Aufgabe befasste, stellte ich fest, dass es wirklich schwierig ist, mit Zeitzonen in dieser Sprache zu arbeiten. Es war äußerst schwierig, etwas Komplizierteres zu implementieren, als nur die Zeitanzeige zu formatieren und das Datum mithilfe komplexer Operationen (Kalenderfunktionen) zu berechnen. Ich habe wertvolle Erfahrungen bei der Lösung dieses Problems gesammelt, was neue Schwierigkeiten mit sich brachte.
In diesem Artikel möchte ich diskutieren, was mir begegnet ist und wie es gelöst wurde. Während ich den Text schrieb, stellte ich fest, dass der Grund für all die Schwierigkeiten mein schlechtes Verständnis des Themas Zeitzonen war. Angesichts dieses Bewusstseins empfehle ich, zunächst ausführlich über die Definition und die Standards zu sprechen und erst dann mit JavaScript fortzufahren.
Was ist eine Zeitzone?
Eine Zeitzone ist eine geografische Region, die dieselbe von der Regierung festgelegte Ortszeit verwendet. Viele Länder beziehen sich ausschließlich auf bestimmte Zeitzonen, und in den Gebieten großer Staaten wie Russland und den Vereinigten Staaten werden mehrere Zeitzonen verwendet. Es ist merkwürdig, dass China zwar auch groß genug ist, aber nur eine Zeitzone akzeptiert. Manchmal führt dies zu seltsamen Situationen, wenn der Sonnenaufgang im Westen des Landes gegen 10 Uhr morgens beginnt.
GMT, UTC und Offset
GMT
Die lokale südkoreanische Zeit wird als
GMT+09:00 . GMT steht für Greenwich Mean Time (GMT), dh diesmal auf der Uhr des Royal Observatory in Greenwich, UK. Es liegt am Nullmeridian. Das Funksignal des GMT-Systems wurde am 5. Februar 1924 ausgestrahlt und am 1. Januar 1972 selbst zum Weltstandard.
UTC
Viele Leute denken, dass GMT und UTC dasselbe sind und verwenden sie oft als austauschbare Systeme. Aber das ist ein Fehler. Das UTC-System erschien 1972, um den Effekt der Erdrotation zu kompensieren. Das System basiert auf der Internationalen Atomzeit, berechnet aus der Frequenz elektromagnetischer Schwingungen von Cäsiumatomen. Mit anderen Worten, UTC ist ein genauerer Ersatz für GMT. Obwohl der Echtzeitunterschied zwischen den beiden Systemen sehr gering ist, ist es für Softwareentwickler besser, sich auf UTC zu verlassen.
Eine interessante Tatsache: Als UTC noch entwickelt wurde, wurde in englischsprachigen Ländern vorgeschlagen, es CUT (Coordinated Universal Time) und in französischsprachigen Ländern TUC (Temps Universal Coordonn) zu nennen. Keines der Lager konnte jedoch gewinnen, und sie stimmten zu, das System UTC zu nennen, wobei beide vorgeschlagenen Optionen (C, T und U) angegeben wurden.
Offset
+09:00 in
UTC+09:00 bedeutet, dass die Ortszeit 9 Stunden vor der Standard-UTC-Zeit liegt. Das heißt, wenn es in Südkorea 21 Uhr ist, ist es in der UTC-Region Mittag. Die Differenz zwischen der Standard-UTC-Zeit und der Ortszeit wird als "Offset" bezeichnet, der als positive oder negative Werte ausgedrückt wird:
+09:00 ,
-03:00 usw.
In vielen Ländern ist es üblich, Ihren Zeitzonen eindeutige Namen zu geben. Beispielsweise wird die Zeitzone Südkoreas als KST (Korea Standard Time) bezeichnet, ihr Versatz wird als
KST = UTC+09:00 ausgedrückt. Der Offset
+09:00 jedoch nicht nur von Südkorea, sondern auch von Japan, Indonesien und vielen anderen Ländern verwendet. Daher wird die Beziehung zwischen Offsets und Riemen nicht als 1: 1, sondern als 1: N ausgedrückt. Eine Liste der Länder mit einem Offset von
+09:00 wird
hier dargestellt .
Einige Offsets arbeiten nicht nur stundenlang. In Nordkorea beträgt die Standardzeit beispielsweise
+08:30 , während in Australien in einigen Regionen
+8:45 ,
+09:30 und
+10:30 .
Eine vollständige Liste der UTC-Offsets finden Sie
hier .
Zeitzone! == Offset?
Wie gesagt, wir verwenden Zeitzonennamen (KST, JST) mit Offsets als austauschbar, ohne zwischen ihnen zu unterscheiden. Es wird jedoch falsch sein, die gleiche Zeit und die Verschiebung einer bestimmten Region zu berücksichtigen. Es gibt mehrere Gründe:
Sommerzeit (DST)
In einigen Ländern ist dieser Begriff unbekannt, aber in vielen Staaten wird Sommerzeit praktiziert, hauptsächlich in Europa. Hierfür wird der internationale Begriff Sommerzeit übernommen - Sommerzeit. Dies bedeutet, dass die Uhr im Sommer eine Stunde vor der relativen Standardzeit bewegt wird.
Beispielsweise verwendet Kalifornien im Winter PST (Pacific Standard Time) und im Winter PDT (Pacific Daylight Time,
UTC-07:00 ). In den USA und Kanada wird der Begriff Pacific Time (PT, Pacific Time) für Regionen verwendet, die zwei Zeitzonen verwenden.
Wann beginnt und endet die Sommerzeit? Es hängt alles vom Land ab. In den USA und Kanada wurde die Sommerzeit beispielsweise bis 2006 von 2 Uhr morgens am ersten Sonntag im April bis 12 Uhr am letzten Sonntag im Oktober verwendet. Und ab 2007 begann die Sommerzeit von 2 Nächten am zweiten Sonntag im März bis zu 2 Nächten am ersten Sonntag im November zu zählen. In Europa praktizieren verschiedene Länder je nach Zeitzone den progressiven Einsatz der Sommerzeit.
Ändern sich Zeitzonen?
Jedes Land selbst bestimmt, welche Zeitzonen verwendet werden sollen, sodass sich die Ortszeit aus politischen und / oder wirtschaftlichen Gründen ändern kann. In den USA wurden beispielsweise die DST-Grenzen 2007 geändert, weil George W. Bush 2005 die Energiepolitik initiierte. Ägypten und Russland haben früher auf Sommerzeit umgestellt, diese aber seit 2011 aufgegeben.
In einigen Fällen kann die Regierung nicht nur die Sommerzeit, sondern auch die Standardzeit ändern. Früher verwendeten Samoa beispielsweise den Offset
UTC-10:00 , wechselten dann jedoch zu
UTC+14:00 , um die Handelsverluste aufgrund des Zeitunterschieds zu Australien und Neuseeland zu verringern. Diese Entscheidung führte zum Tod des Landes einen ganzen Tag - den 30. Dezember 2011, wie
Zeitungen auf der ganzen Welt berichteten .
In den Niederlanden wird seit 1909 ein Offset von
+0:19:32.13 verwendet, seit 1937 wurde das Land auf
+00:20 und von 1940 auf
+01:00 umgestellt, seitdem hat sich die Hauptzeit dort nicht geändert.
Zeitzone 1: Offset N.
Die Zeitzone kann also einen oder mehrere Offsets haben. Welche Zeit als Standard akzeptiert wird, hängt von den aktuellen politischen und / oder wirtschaftlichen Gründen in einem bestimmten Land ab.
Im Alltag verursacht dies keine Schwierigkeiten, bis Sie versuchen, diese Daten anhand einiger Regeln zu systematisieren. Stellen Sie sich vor, Sie möchten die Standardzeit auf Ihrem Smartphone mit einer Art Voreingenommenheit einstellen. Wenn Sie in einer Region leben, in der Sommerzeit praktiziert wird, sollte Ihr Smartphone genau wissen, wann Sie hin und her gehen müssen. Das heißt, Sie müssen die Beziehung zwischen Standard- und Sommerzeit in einer Zeitzone (z. B. Pacific Time) herstellen.
Dies kann jedoch nicht mit ein paar einfachen Regeln erreicht werden. Als beispielsweise in den USA 2007 der Beginn und das Ende der Sommerzeit geändert wurden, sollte am 31. Mai 2006 PDT (
-07:00 ) als Standardzeit und am 31. März 2007 - PST (
-08:00 ) verwendet werden. Es stellt sich heraus, dass Sie, um sich auf eine bestimmte Zeitzone zu beziehen, den gesamten Verlauf der Änderung der Zeitzonen oder das Datum der Änderung der Sommerzeitregeln kennen müssen.
Sie können sagen: "Die Zeitzone in New York ist PST (
-08:00 )." Es muss jedoch klargestellt werden: „Die aktuelle Zeitzone in New York ist PST.“ Darüber hinaus müssen Sie für eine genaue Implementierung des Systems einen noch genaueren Ausdruck verwenden. Vergessen Sie den Begriff "Zeitzone". Sie müssen sagen: "Jetzt in New York wird PST als Standardzeit verwendet."
Was sollten wir also anstelle des Versatzes verwenden, um die Zeitzone einer bestimmten Region zu bestimmen? Der Name dieser Region. Genauer gesagt sollten Sie die Regionen, in denen sie gleichermaßen auf Sommer- und Standardzeit umschalten, in einer einzigen Zeitzone gruppieren. Sie können Namen wie PT (Pacific Time) verwenden, diese kombinieren jedoch nur die aktuelle Standardzeit und die Sommerzeit und berücksichtigen nicht unbedingt alle historischen Änderungen. Da PT nur in den USA und Kanada im Umlauf ist, müssen Sie sich außerdem auf die etablierten Standards seriöser Organisationen verlassen, um die Universalität Ihrer Software sicherzustellen.
IANA-Zeitzonendatenbank
Ich muss zugeben, dass Informationen über Zeitzonen eher eine Datenbank als ein Regelwerk sind, da diese Informationen alle relevanten historischen Änderungen enthalten sollten. Es gibt mehrere Standarddatenbanken zum Lösen von Aufgaben in Bezug auf Zeitzonen. Am häufigsten wird die
IANA-Zeitzonendatenbank verwendet , die normalerweise als tz-Datenbank (oder tzdata) bezeichnet wird. Die Datenbank enthält historische Daten zu Änderungen der Standardzeit und der Sommerzeit weltweit. Darüber hinaus ist es so organisiert, dass es möglich ist, alle historischen Daten zu überprüfen und sicherzustellen, dass die Zeit ab der Unix-Zeit (
1970.01/01 00:00:00 )
1970.01/01 00:00:00 . Obwohl Sie Informationen bereits vor 1970 in der Datenbank finden können, kann deren Richtigkeit nicht garantiert werden.
Die Namenskonvention verwendet die Regions- / Ortsregel. Der Name des Kontinents oder Ozeans (Asien, Amerika, Pazifik) wird normalerweise als Region und die Namen der Hauptstädte (Seoul, New York) als Ort verwendet. Der Grund ist, dass Städte normalerweise länger dauern als Länder. Südkoreas Zeitzone ist beispielsweise
Asia/Seoul und Japans
Asia/Tokyo . Obwohl beide Länder denselben
UTC+09:00 Offset verwenden, hat sich ihre Ortszeit unterschiedlich geändert, sodass sie in verschiedene Zeitzonen unterteilt wurden.
Die IANA-Basis wird von vielen Entwickler- und Historikergemeinschaften betrieben. Frisch gefundene historische Daten werden sofort eingegeben und die aktuellen Richtlinien werden aktualisiert, sodass die Datenbank heute als die zuverlässigste Quelle angesehen werden kann. Darüber hinaus wird es von vielen Unix-Systemen, einschließlich Linux und MacOS, sowie einer Reihe gängiger Programmiersprachen, einschließlich Java und PHP, unter der Haube verwendet.
Bitte beachten Sie, dass Windows
die Microsoft-Datenbank verwendet . Es ist jedoch in Bezug auf historische Daten ungenau und wird nur von Microsoft selbst unterstützt. Daher ist die Basis weniger zuverlässig als die IANA-Basis.
JavaScript und IANA
Zeitzonenbezogene Funktionen werden aus heiterem Himmel in JavaScript implementiert. Standardmäßig verwendet die Sprache den aktuellen Regionsgürtel (genauer gesagt den bei der Installation des Betriebssystems ausgewählten Gürtel), und es gibt keine Möglichkeit, ihn zu ändern. Darüber hinaus sind selbst die Spezifikationen für den Datenbankstandard in JavaScript vage, und Sie werden dies selbst verstehen, wenn Sie sich für die Spezifikation für ES2015 entscheiden. Über die lokale Zeitzone und die Verfügbarkeit der Sommerzeit gibt es nur einige vage Aussagen. Die Sommerzeit ist beispielsweise wie folgt definiert:
ECMAScript 2015 - Anpassung der Sommerzeit .
Dies ist ein implementierungsabhängiger Algorithmus, der die besten verfügbaren Zeitzoneninformationen verwendet, um die lokale Sommerzeiteinstellung DaylightSavingTA (t) zu bestimmen, die in Millisekunden berechnet wird. Eine ECMAScript-Implementierung soll Ihnen helfen, Ihre lokale Sommerzeiteinstellung besser zu bestimmen.
Sieht so aus, als würden sie nur sagen: "Leute, versuchen Sie, das zum Laufen zu bringen." Unter anderem müssen Sie das Kompatibilitätsproblem mit verschiedenen Browsern lösen. Sie sagen: "Was für ein Durcheinander!" Und lesen dann die folgende Zeile:
Hinweis: Wir empfehlen, dass Sie in Ihren Implementierungen Informationen aus der IANA-Zeitzonendatenbank http://www.iana.org/time-zones/ verwenden .
Ja ECMA-Spezifikationen geben Ihnen den Ball mit einer solch unprätentiösen Empfehlung, die IANA-Datenbank zu verwenden, da JavaScript keine spezielle Standarddatenbank hat. Infolgedessen verwenden verschiedene Browser ihre eigenen Vorgänge mit Zeitzonen, die häufig nicht miteinander kompatibel sind, um die Zeit zu berechnen. Später wurde in ECMA für die internationale API die Option zur Verwendung von IANA-Daten im ECMA-402
Intl.DateTimeFormat Format
Intl.DateTimeFormat . Diese Option ist jedoch viel weniger zuverlässig als Analoga in anderen Programmiersprachen.
Zeitzone in Server-Client-Umgebung
Stellen Sie sich ein einfaches Szenario vor: Wir müssen die Zeitzone bestimmen. Angenommen, wir erstellen einen Kalender, der Zeitinformationen verarbeitet. Wenn ein Benutzer in der Clientumgebung ein Datum und eine Uhrzeit in das Registrierungsfenster eingibt, wird das Datum auf den Server übertragen und in der Datenbank gespeichert. Anschließend erhält der Client vom Server das Datum, das im Zeitplan für die Anzeige auf dem Bildschirm registriert ist.
Hier müssen Sie etwas entscheiden. Was ist, wenn sich einige der Clients, die auf den Server zugreifen, in unterschiedlichen Zeitzonen befinden? Die Veranstaltung im Zeitplan, die am 10. März 2017 um 23.30 Uhr in Seoul in New York registriert wurde, sollte als 10. März 2017 um 9.30 Uhr angezeigt werden. Damit der Server Clients aus verschiedenen Zeitzonen bedienen kann, muss der darauf gespeicherte Zeitplan Absolutwerte enthalten, die nicht von der Zone abhängen. Jeder Server hat seine eigene Art, solche Werte zu speichern. Diese Frage geht über den Rahmen des Artikels hinaus, da alles von einem bestimmten Server oder einer bestimmten Datenbank abhängt. Im Allgemeinen sollten Datum und Uhrzeit, die vom Client an den Server übertragen werden, entweder in Form von Werten dargestellt werden, die auf einem einzelnen Offset basieren (normalerweise UTC), oder in Form von Werten, die Informationen über die Zeitzone der Clientumgebung enthalten.
In der Regel werden solche Daten als
Unix-Zeit im UTC-Format oder gemäß dem
ISO-8601- Standard mit Offset-Informationen übertragen. Wenn wir in unserem Beispiel Seoul 21.30 am 10. März 2017 in Unix-Zeit konvertieren, erhalten wir den ganzzahligen Wert
1489113000 . Im ISO-8601-Format lautet der Zeichenfolgenwert
2017–03–10T11:30:00+09:00 .
Wenn Sie JavaScript in einer Browserumgebung verwenden, müssen Sie den eingegebenen Wert wie oben beschrieben konvertieren und dann zurückkonvertieren, um ihn an die Zeitzone des Benutzers anzupassen. Beide Probleme müssen gelöst werden. Aus Sicht der Programmiersprache wird die erste Operation als "Parsen" und die zweite als "Formatieren" bezeichnet. Nun wollen wir sehen, wie dies in JavaScript gemacht wird.
Selbst wenn Sie mit JS in einer Serverumgebung mit Node.js arbeiten, müssen Sie möglicherweise die vom Client empfangenen Daten analysieren. Da die Zeitzonen von Servern und Datenbanken normalerweise synchronisiert sind und die Formatierung den Clients zugewiesen wird, müssen Sie in einer Browserumgebung mehrere Faktoren festlegen. Weiter werde ich in Bezug auf die Browser-Umgebung erklären.
JavaScript-Datumsobjekt
Aufgaben, bei denen mit einer bestimmten Zeit oder Zeit gearbeitet wird, werden mit dem
Date Objekt gelöst. Dies ist ein natives Objekt, das in ECMAScript definiert ist, z. B.
Array oder
Function . Das heißt, es wird größtenteils mit nativem Code wie C ++ implementiert. Die API ist in der
MDN-Dokumentation ausführlich beschrieben. Die Klasse
java.util.Date aus Java hatte einen großen Einfluss auf das Objekt und erbte daher einige unerwünschte Eigenschaften, wie z. B. Eigenschaften veränderlicher Daten und einen Monat ab Null.
Unter der Haube arbeitet ein JavaScript-
Date mit der Zeit unter Verwendung von Absolutwerten im Unix-Zeitformat. Konstruktoren und Methoden wie die Funktionen
getHour() parse() ,
getHour() ,
setHour() und andere sind jedoch von der Zeitzone des Clients betroffen (genauer gesagt vom Gürtel, der in dem Betriebssystem angegeben ist, in dem der Browser ausgeführt wird). Wenn Sie also ein
Date direkt mit vom Benutzer eingegebenen Daten erstellen, wird die lokale Zeitzone des Clients in diesen Daten wiedergegeben.
Wie bereits erwähnt, bietet JavaScript keine Möglichkeit, die Zeitzone willkürlich zu ändern. Wir gehen daher davon aus, dass wir den im Browser angegebenen Zeitzonenwert direkt verwenden können.
Erstellen eines Datumsobjekts mithilfe von Benutzereingaben
Kehren wir zum ersten Beispiel zurück. Angenommen, ein Benutzer hat am 11. März 2017 um 11.30 Uhr die Seoul-Zeit auf seinem Gerät eingegeben. Diese Daten werden als fünf Zahlen gespeichert: 2017, 2, 11, 11 und 30 - Jahr, Monat, Tag, Stunden und Minuten (da der Monat bei 0 beginnt) Der Wert sollte 3–1 = 2 sein. Mit dem Konstruktor können Sie ganz einfach ein
Date erstellen:
const d1 = new Date(2017, 2, 11, 11, 30); d1.toString();
Wenn Sie sich den von
d1.toString() Wert
d1.toString() , werden Sie
d1.toString() , dass der absolute Wert des erstellten Objekts am 11. März 2017 11:00 Uhr ist. Er wurde mit der
+09:00 (KST) berechnet.
Sie können Zeichenfolgendaten im Konstruktor verwenden. Wenn Sie sie auf
Date anwenden, ruft das Objekt intern
Date.parse() und
Date.parse() korrekten Wert. Diese Funktion unterstützt die
Spezifikationen RFC2888 und
ISO-8601 . In der
MDN-Dokumentation für Date.parse () heißt es jedoch, dass der von dieser Methode zurückgegebene Wert vom Browser abhängt und das Format des Zeichenfolgentyps den genauen Endwert beeinflussen kann. Daher ist es besser, diese Methode nicht zu verwenden. In Safari und Internet Explorer gibt beispielsweise ein Zeichenfolgenwert wie
2015–10–12 12:00:00 NaN , während in Chrome und Firefox die lokale Zeitzone zurückgegeben wird. In einigen Situationen wird ein UTC-basierter Wert zurückgegeben.
Erstellen eines Datumsobjekts mithilfe von Serverdaten
Angenommen, Sie möchten Daten von einem Server empfangen. Wenn sie die Form einer numerischen Unix-Zeit haben, können Sie einfach den Konstruktor verwenden, um ein
Date zu erstellen. Ich habe noch nicht erwähnt, dass der
Date Konstruktor, wenn er einen einzelnen Wert als einzelnen Parameter empfängt, den Unix-Zeitwert in Millisekunden berechnet (Hinweis: JS verarbeitet die Unix-Zeit in Millisekunden. Dies bedeutet, dass der zweite Wert mit 1000 multipliziert werden muss). Bei der Ausführung des folgenden Codes erhalten wir den gleichen Wert wie im vorherigen Beispiel:
const d1 = new Date(1489199400000); d1.toString();
Und wenn anstelle von Unix-Zeit der String-Typ ISO-8601 verwendet wird? Wie ich oben erklärt habe, wird die
Date.parse() -Methode unzuverlässig und es ist besser, sie nicht zu verwenden. Ab ECMAScript 5 können Sie jedoch Zeichenfolgenkonstruktionen im ISO-8601-Format im
Date in Internet Explorer 9.0 und höher verwenden.
Wenn Sie nicht den neuesten Browser verwenden, stellen Sie sicher, dass sich das
Z am Ende der Werte befindet. Ohne sie kann Ihr alter Browser den Wert basierend auf der Ortszeit und nicht auf UTC interpretieren. Hier ist ein Beispiel für die Verwendung in Internet Explorer 10:
const d1 = new Date('2017-03-11T11:30:00'); const d2 = new Date('2017-03-11T11:30:00Z'); d1.toString();
Gemäß der Spezifikation sollte in beiden Fällen der gleiche Wert erhalten werden. Aber sie sind anders. In einem späteren Browser sind die Werte gleich. Um dieses Problem zu vermeiden, fügen Sie immer
Z am Ende der Zeile hinzu, wenn keine Zeitzoneninformationen verfügbar sind.
Erstellen eines Datums für die Übergabe an den Server
Jetzt können Sie das zuvor erstellte
Date , die Zeit basierend auf lokalen Zeitzonen frei abrufen oder hinzufügen. Vergessen Sie erst am Ende der Verarbeitung, die Daten in das vorherige Format zu konvertieren, bevor Sie sie an den Server zurückgeben.
Wenn dies Unix-Zeit ist, können Sie die Methode
getTime() verwenden (Millisekunden nicht vergessen).
const d1 = new Date(2017, 2, 11, 11, 30); d1.getTime();
Was ist mit einem Zeichenfolgenwert im ISO-8601-Format? Wie bereits erwähnt, unterstützen Internet Explorer 9.0 und höher ECMAScript 5 und spätere Versionen unterstützen ISO-8601. Daher können Sie mit den
toISOString() oder
toJSON() eine Zeichenfolge in ISO-8601
toJSON() kann für rekursive Aufrufe mit
JSON.stringify() und anderen verwendet werden). Beide Methoden liefern das gleiche Ergebnis, außer bei der Verarbeitung ungültiger Daten:
const d1 = new Date(2017, 2, 11, 11, 30); d1.toISOString();
Sie können die
toGMTString() oder
toUTCString() verwenden, um eine UTC-Zeichenfolge zu erstellen. Dies führt zu einem Wert, der
RFC-1123 entspricht .
Das
Date Objekt enthält
toString() ,
toLocaleString() und deren Erweiterungsmethoden. Sie sind jedoch von geringem Nutzen, da sie hauptsächlich zur Rückgabe von Zeichenfolgen basierend auf der lokalen Zeitzone verwendet werden und die zurückgegebenen Werte vom Browser und vom Betriebssystem abhängen.
Ändern Sie Ihre lokale Zeitzone
Wie Sie sehen können, gibt es in JS eine Art Zeitzonenunterstützung. Und wenn Sie den lokalen Gürtel in der Anwendung ändern müssen, ohne den im Betriebssystem angegebenen Wert zu berücksichtigen? ? , JS . , . . , .
. . 11.30 11 2017 - . Unix- , -
-05:00 . , .
getTimeZoneOffset() . API JavaScript, . :
const seoul = new Date(1489199400000); seoul.getTimeZoneOffset();
-540 , 540 . , (
+09:00 ). , , . -,
60 * 5 = 300 .
840 Date .
getXX . :
function formatDate(date) { return date.getFullYear() + '/' + (date.getMonth() + 1) + '/' + date.getDate() + ' ' + date.getHours() + ':' + date.getMinutes(); } const seoul = new Date(1489199400000); const ny = new Date(1489199400000 - (840 * 60 * 1000)); formatDate(seoul);
formatDate() -. , . , ? , . , — , . ( ).
, . , -, 11 15 .
setDate() Date , , .
ny.setDate(15); formatDate(ny);
, . , ? ,
getTime() getISOString() . , .
const time = ny.getTime() + (840 * 60 * 1000);
, , .
Date ? Nein.
Date 11- 15-, 4 (
24 * 4 * 60 * 60 * 1000 ). - 10- 15-, 5 (
24* 5 * 60 * 60 * 1000 ). .
. , . - 12 , 15 2017
-04:00 ,
-05:00 . , 780 , 60 , .
const time = ny.getTime() + (780 * 60 * 1000);
, - , .
, . , , , . , ,
IANA .
,
Date , . , . , . . JS . .
Moment Timezone
Moment — JavaScript-, . API , .
Moment Timezone , . IANA API, .
. , .
.
, Moment Timezone:
const seoul = moment(1489199400000).tz('Asia/Seoul'); const ny = moment(1489199400000).tz('America/New_York'); seoul.format();
seoul ,
ny -05:00 -04:00 .
format() , ISO-8601, . .
Fazit
API , JavaScript, . , API, Internet Explorer 9 . , . ,
getTimezoneOffset() . , . Moment Timezone.
, , . : . , , , . , JavaScript . , .
Nützliche Links