JavaScript UTC Date

[Woodz]

Hallo.

Wie schaffe ich es ein Date-Object in UTC zu erstellen? Ich habe mal ein bisschen rumprobiert, aber die gängigen Funktionen liefern mir immer nur die Mitteleuropäische Sommerzeit bzw. Mitteleuropäische Normalzeit:

<script>
    let t = new Date('2019-10-20T02:00:00Z');
    // liefert: Sun Oct 20 2019 04:00:00 GMT+0200 (Mitteleuropäische Sommerzeit)
    
    let dt = new Date(Date.UTC(2019, 9, 20, 2, 0, 0));
    // liefert: Sun Oct 20 2019 04:00:00 GMT+0200 (Mitteleuropäische Sommerzeit)
</script>

Ich möchte allerdings das das Datum in UTC angegeben wird, folglich:
"Sun Oct 20 2019 02:00:00 GMT"

Ich möchte dabei aber das Date--Objekt beibehalten, damit ich damit rechnen kann, d.h. .toUTCString hilft mir hier nicht weiter, da es einen einfachen String ausgibt.

Hat jemand eine Idee?

 

[Andreas_]

Wenn nicht anders angegeben, dann arbeiten die Date-Funktionen bei der Ausgabe mit der lokalen Zeitzone. Du hast ja selbst schon herausgefunden, dass Du dies mit .toUTCString ändern kannst. Mit .toLocaleString() kannst Du für die Ausgabe auch andere Zeitzonen wählen.

Aber anscheinend ist Dir nicht klar, dass "Oct 20 2019 02:00:00 GMT+0000" derselbe Datumswert ist wie "Oct 20 2019 04:00:00 GMT+0200". Der Date-Wert ist die Anzahl der Millisekunden seit dem 1. Januar 1970 UTC und die ist bei beiden Datumsangaben dieselbe - nämlich 1571536800000.

 

[blablub1212]

Zeiten sind meiner Meinung nach immer nervig und da kann man sich ruhig mal eine kleine Hilfe gönnen

Ich nutze für sowas https://momentjs.com/ das bringt auch gleich ein paar Rechenfunktionen mit.

 

[abcddcba]

Ich möchte dabei aber das Date--Objekt beibehalten, damit ich damit rechnen kann

Es ist doch wie Andreas schon sagte auch alles so richtig. Ueberlege doch mal, zum Zeitpunkt X, und genau der ist im Objekt codiert, ist es nun mal je nach Zeitzone eine andere Uhrzeit. Aendert doch aber nix daran wenn du z.B. 2h dazu rechnest. Am Ende kommt doch trotzdem die gleiche semantisch korrekte Ausgabe, mit toUTCString

 

[benneq]

Ich nutze für sowas https://momentjs.com/ das bringt auch gleich ein paar Rechenfunktionen mit.

Wenn dann gleich den Nachfolger: Luxon. Sehr ähnlich, aber ohne die meisten Unzulänglichkeiten von moment.
Oder man bastelt sich selbst was mit date-fns.

 

[Woodz]

Ok, ich danke Euch. Ich finde es halt nur etwas verwirrend, dass ich ein Date-Objekt für 02:00 Uhr UTC definiere, der Output aber in MESZ geliefert wird und nicht in UTC.

 

[benneq]

@Woodz Das JavaScript Date Objekt speichert intern einfach nur die aktuelle Uhrzeit in deiner(!) Zeitzone. Nicht mehr, nicht weniger. Da kannst du definieren was du willst, am Ende steht immer MESZ drin.

Stell dir die darin enthaltenen Daten wie folgt vor:
timestamp: 1572041863564 (Millisekunden seit 1.1.1970)

Die Methode "getTimezoneOffset" auf den Date Objekten ist keine wirkliche Objekt Methode, weil der Rückgabewert überhaupt nichts mit dem Objekt zu tun hat, sondern eher eine statische Methode, die dir das Offset von UTC zur Zeitzone deines Hostsystems ausgibt.

Das Date Objekt in JavaScript ist aber generell ziemlich mies. Damit will man unter keinen Umständen arbeiten. Angeblich wird seit geraumer Zeit an einem würdigen Nachfolger gearbeitet, aber keine Ahnung wie weit die Herrschaften sind.

In Java gab's ähnliche Probleme. Dort gibt es 3(!) unterschiedliche "Date" Klassen. Und erst mit der dritten Iteration in Java 8 wurde es endlich vernünftig umgesetzt. Ähnlich wie moment.js oder Luxon.

 

[Andreas_]

@benneq
Wenn Du Dir mit getTime den Wert eines Date-Objekts ausgeben lässt, dann wirst Du feststellen, dass immer UTC "drin steht" ist und niemals MESZ. Das ist genau das, was Woodz zu mindestens beim Erstellen dieses Threads noch nicht verstanden hatte.

Auch heißt es bei Mozilla auch zum Date-Objekt:

Erstellt eine JavaScript Date Instanz, die einen einzelnen Moment der Zeit repräsentiert. Date Objekte basieren auf dem Zeitwert, der der Anzahl der Millisekunden seit dem 1. Januar 1970 (UTC) entspricht.

Das Date-Objekt ist also immer UTC. Lediglich werden bei Ausgaben die lokalen Einstellungen genutzt, was auch der Grund ist, dass man für dasselbe DateObjekt je nach der Zeitzone in der man sich aufhält eine andere Ausgabe erhält.

Morgen ist Zeitumstellung und auch da wird sich die Ausgabe ändern.

 

[Woodz]

Da ich das Prinzip jetzt verstanden habe, ist die Sache an sich ziemlich simple. Die Ausgabe interessiert mich jetzt nicht mehr, denn intern rechne ich nun nur noch mit ms und ziehe mir dann über "getUTC...()" die notwendigen Angaben heraus.
Nochmals Danke für Eure Hilfe.