Ich habe Chrome auf Version 67 aktualisiert. Und ich bekomme einen Fehler mit dem Datum
==============
Microsoft Edge 42.17134.1.0
new Date("1900-01-01T00:00:00").getTimezoneOffset()
-180
new Date("2018-05-30T00:00:00").getTimezoneOffset()
-180
Microsoft Internet Explorer 11.48.17134.0
new Date("1900-01-01T00:00:00").getTimezoneOffset()
-180
new Date("2018-05-30T00:00:00").getTimezoneOffset()
-180
Mozilla Firefox 60.0.1
new Date("1900-01-01T00:00:00").getTimezoneOffset()
-180
new Date("2018-05-30T00:00:00").getTimezoneOffset()
-180
Chrom 67.0.3396.62
new Date("1900-01-01T00:00:00").getTimezoneOffset()
-150
new Date("2018-05-30T00:00:00").getTimezoneOffset()
-180
======================
-150 in Chrom 67…
Ein weiteres Beispiel (Chrome 67):
new Date("1900-01-01T00:00:00");
Mon Jan 01 1900 00:00:00 GMT+0230 (Moscow Standard Time)
======================
Bei Chrome 67 begannen die Zeitzonen falsch (+0230, war: +0300)
Bitte sagen Sie mir?
Was kann ich tun ?
Die Situation ist sehr wichtig! Den ganzen Code muss ich umschreiben…
======================
Historische Daten, Zeiten und Zeitzonen sind äußerst komplex, wenn Sie genaue Berechnungen durchführen möchten. Sie sind heute immer noch ein bisschen chaotisch, aber viel einfacher als früher. Sie können nicht erwarten, dass eine Javascript-Implementierung alle Offsets für alle Daten für alle Zeitzonen und Regionen enthält (insbesondere wenn in Javascript “Gebietsschema” tatsächlich ein Sprachcode und kein Ort ist). Wenn Sie das möchten, verwenden Sie eine Bibliothek mit einer geeigneten Datenbank mit genauen Offsets basierend auf Orten (nicht Sprachen), wie die IANA-Zeitzonendatenbank.
– RobG
31. Mai 2018 um 11:20 Uhr
RobG, danke! Können Sie einige Bibliotheken (in Javascript) mit einer geeigneten Datenbank sagen …?
– Alexej
31. Mai 2018 um 13:23 Uhr
Anfragen nach externen Ressourcen sind hier kein Thema. Sie könnten mit beginnen Moment Zeitzone, das eine Erweiterung von moment.js ist und Daten aus der IANA-Zeitzonendatenbank verwendet. Ich weiß jedoch nicht, wie weit die Unterstützung für historische Daten zurückreicht oder wie umfangreich oder genau sie ist.
– RobG
31. Mai 2018 um 13:41 Uhr
Danke! Ich habe Code mit momentjs angepasst. Und ich bekomme ein weiteres Problem. Der Kunde hat mit Zeitzonen gelernt. Kein Problem auf dem Client mit “1900-01-01T00:00:00+02:30”, aber ich habe ein Problem mit dem Datum vom Server “1900-01-01T00:00:00+03:00”. Es wird das Jahr 1899, minus 30 Minuten! Wie kann ich es lösen? Ich habe den Client mit Chrome 67 gelernt und wie funktioniert der Client mit anderen Browsern? Entschuldigung für mein Deutsch!
– Alexej
31. Mai 2018 um 18:02 Uhr
@Alexey: Das ist ein separates Problem, zu dem Sie in einer neuen Frage viel mehr Kontext geben müssen. RobG und ich haben erklärt, warum Sie möglicherweise unterschiedliche Offsets sehen, insbesondere für Datums-/Uhrzeitwerte vor langer Zeit. Darum ging es bei dieser Frage. Wenn Sie wissen möchten, wie Sie damit am besten umgehen, müssen Sie weitere Informationen darüber bereitstellen, was Sie zu tun versuchen und welchen Code Sie haben.
– Jon Skeet
1. Juni 2018 um 5:54 Uhr
Jon Skeet
Ich gehe davon aus, dass Sie sich in der Zeitzone Europa/Moskau befinden – das scheint angesichts der von Ihnen bereitgestellten Ausgabe wahrscheinlich.
Im Jahr 1900 hatte die Zeitzone Europa/Moskau einen Versatz von +02:30:17, gemäß der IANA-Zeitzonendatenbank. Vermutlich rundet Chrome auf 02:30 ab, um Abweichungen von weniger als einer Minute zu vermeiden, aber soweit ich sehen kann, gibt es angemessene Daten zurück. Der Versatz in Russland wurde 1919 erstmals zu einer ganzen Zahl von Stunden, zumindest laut IANA-Datenbank.
Sie sollten sich wohl fragen, warum die andere Browser tun das nicht – aber wahrscheinlicher sollten Sie Ihren Code so ändern, dass er nicht nach Zeitzoneninformationen vor 1970 fragt. Die IANA-Datenbank zielt darauf ab, genaue Daten ab der Unix-Epoche bereitzustellen; alles frühere ist sehr viel “best effort”. Von dem Theorie Datei:
Zeitübergänge vor 1970 werden für jeden dieser Orte aufgezeichnet, da die meisten Systeme Zeitstempel vor 1970 unterstützen und sich falsch verhalten könnten, wenn Dateneinträge für Übergänge vor 1970 weggelassen würden. Die Datenbank ist jedoch nicht für Anwendungen ausgelegt und reicht nicht aus, die überall eine genaue Handhabung aller vergangenen Zeiten erfordern, da es viel zu viel Aufwand und Rätselraten erfordern würde, alle Details der zivilen Zeitmessung vor 1970 zu erfassen. Obwohl einige Informationen außerhalb des Gültigkeitsbereichs der Datenbank in einer Datei-Backzone gesammelt werden, die zusammen mit der eigentlichen Datenbank verteilt wird, ist diese Datei weniger zuverlässig und folgt nicht unbedingt den Datenbankrichtlinien.
In Bezug darauf, warum Sie dies mit Chrome 67 sehen, wenn Sie es nicht mit früheren Versionen von Chrome sehen, frage ich mich, ob Chrome gerade damit begonnen hat, IANA-Zeitzonendaten zu bündeln, anstatt die Betriebssystemdaten zu verwenden.
Dieses Verhalten wird durch die jüngsten Änderungen in der ECMA-Spezifikation und deren Implementierung bestimmt (scheint, dass diese Änderungen bisher nur in Chrome implementiert wurden) – Quelle: chromium-review.googlesource.com/c/v8/v8/+/572148
– Krzysztof Grzybek
21. Juni 2018 um 13:11 Uhr
Ich hatte einige ähnliche Probleme bei der Verwendung von new Date(".."); Konstrukteur. (auch seit Änderung der Chrome-Version)
Hinweis: Vom Analysieren von Datumszeichenfolgen mit dem Date-Konstruktor (und Date.parse, sie sind äquivalent) wird aufgrund von Browserunterschieden und -inkonsistenzen dringend abgeraten. Die Unterstützung für Zeichenfolgen im RFC 2822-Format erfolgt nur per Konvention. Die Unterstützung für ISO 8601-Formate unterscheidet sich darin, dass Nur-Datum-Strings (z. B. “1970-01-01”) als UTC und nicht als lokal behandelt werden.
Vielleicht ist es in Ihrem Code möglich, einen anderen Datumskonstruktor zu verwenden wie:
Historische Daten, Zeiten und Zeitzonen sind äußerst komplex, wenn Sie genaue Berechnungen durchführen möchten. Sie sind heute immer noch ein bisschen chaotisch, aber viel einfacher als früher. Sie können nicht erwarten, dass eine Javascript-Implementierung alle Offsets für alle Daten für alle Zeitzonen und Regionen enthält (insbesondere wenn in Javascript “Gebietsschema” tatsächlich ein Sprachcode und kein Ort ist). Wenn Sie das möchten, verwenden Sie eine Bibliothek mit einer geeigneten Datenbank mit genauen Offsets basierend auf Orten (nicht Sprachen), wie die IANA-Zeitzonendatenbank.
– RobG
31. Mai 2018 um 11:20 Uhr
RobG, danke! Können Sie einige Bibliotheken (in Javascript) mit einer geeigneten Datenbank sagen …?
– Alexej
31. Mai 2018 um 13:23 Uhr
Anfragen nach externen Ressourcen sind hier kein Thema. Sie könnten mit beginnen Moment Zeitzone, das eine Erweiterung von moment.js ist und Daten aus der IANA-Zeitzonendatenbank verwendet. Ich weiß jedoch nicht, wie weit die Unterstützung für historische Daten zurückreicht oder wie umfangreich oder genau sie ist.
– RobG
31. Mai 2018 um 13:41 Uhr
Danke! Ich habe Code mit momentjs angepasst. Und ich bekomme ein weiteres Problem. Der Kunde hat mit Zeitzonen gelernt. Kein Problem auf dem Client mit “1900-01-01T00:00:00+02:30”, aber ich habe ein Problem mit dem Datum vom Server “1900-01-01T00:00:00+03:00”. Es wird das Jahr 1899, minus 30 Minuten! Wie kann ich es lösen? Ich habe den Client mit Chrome 67 gelernt und wie funktioniert der Client mit anderen Browsern? Entschuldigung für mein Deutsch!
– Alexej
31. Mai 2018 um 18:02 Uhr
@Alexey: Das ist ein separates Problem, zu dem Sie in einer neuen Frage viel mehr Kontext geben müssen. RobG und ich haben erklärt, warum Sie möglicherweise unterschiedliche Offsets sehen, insbesondere für Datums-/Uhrzeitwerte vor langer Zeit. Darum ging es bei dieser Frage. Wenn Sie wissen möchten, wie Sie damit am besten umgehen, müssen Sie weitere Informationen darüber bereitstellen, was Sie zu tun versuchen und welchen Code Sie haben.
– Jon Skeet
1. Juni 2018 um 5:54 Uhr