Im Allgemeinen denke ich, dass das Verarbeiten von Daten in der Programmierung ein ziemlich langwieriger Prozess ist, aber ich werde Ihnen sagen, dass es beim Umgang mit alten Daten problematischer sein wird. Der Beispielcode ist in Java geschrieben, aber ich denke, dass ähnliche Probleme in anderen Sprachen auftreten werden.
LocalDateTime.of(1887, 1, 1, 0, 0).atZone(ZoneId.of("Asia/Tokyo"));
// 1887-01-01T00:00+09:18:59[Asia/Tokyo]
Der Zeitzonenversatz in der japanischen Standardzeit beträgt grundsätzlich "+09: 00". Wenn Sie jedoch 1887 angeben, beträgt der Zeitzonenversatz "+09: 18: 59". Da auch Sekunden enthalten sind und sich vom allgemeinen Format unterscheiden. Wenn dieser Wert beispielsweise auf dem Server generiert und an den Client zurückgegeben wird, können Probleme wie Fehler beim Parsen mit JavaScript-Code auf der Front-End-Seite auftreten. (passiert)
Das liegt daran, dass die tz-Datenbank dies tatsächlich tut. Wie der Name schon sagt, ist die tz-Datenbank eine Datenbank mit Zeitzoneninformationen. In Java wird es mit JRE gebündelt und von der Bibliothek referenziert, die Datum und Uhrzeit in Java verarbeitet.
Die aktuelle japanische Standardzeit begann am 1. Januar 1888 und war zuvor anders, so dass sich dies in der tz-Datenbank widerspiegelt.
Dies ist ein Beispiel, bei dem sich das Ergebnis nach Java 8 zwischen der alten und der neuen API ändert.
Zuerst von der alten API.
var cal = Calendar.getInstance();
cal.clear();
cal.set(1582, Calendar.OCTOBER, 4);
var sdf = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
sdf.format(cal.getTime()); // "1582-10-04 00:00:00"
Ich habe 1582/10/4 angegeben und es wurde so ausgegeben, wie es ist. Was ist also mit der neuen API?
var cal = Calendar.getInstance();
cal.clear();
cal.set(1582, Calendar.OCTOBER, 4);
LocalDateTime.ofInstant(cal.toInstant(), ZoneId.of("Asia/Tokyo"));
// 1582-10-14T00:18:59
Es war um 10 Tage aus.
Dies liegt daran, dass verschiedene Bibliotheken vor dem 15. Oktober 1582 unterschiedlich behandelt werden. Der 15. Oktober 1582 ist ein besonderes Datum, an dem der aktuelle Gregorio-Kalender eingeführt wurde. Zuvor wurde der Julius-Kalender verwendet. Daher ist es in eine Bibliothek unterteilt, die den Tag vor dem 15. Oktober 1582 als Julius-Kalender behandelt, und eine Bibliothek, die ihn als Pseudo-Gregorio-Kalender behandelt (Start des Gregorio-Kalenders). In Java ist die alte API die frühere und die neue Das Ergebnis hat sich geändert, da sich die API von der letzteren unterscheidet.
Darüber hinaus wurde der Übergang vom Julius-Kalender zum Gregorio-Kalender mit dem Tag nach dem 4. Oktober 1582 im Julius-Kalender als 15. Oktober 1582 im Gregorio-Kalender durchgeführt. Mit anderen Worten, es flog tatsächlich 10 Tage lang, sodass sich der Unterschied als Ergebnis der Verarbeitung der Datumsbibliothek herausstellte.
LocalDateTime.of(1950, 8, 1, 0, 0).atZone(ZoneId.of("Asia/Tokyo"));
// 1950-08-01T00:00+10:00[Asia/Tokyo]
Der Zeitzonenversatz in der japanischen Standardzeit beträgt grundsätzlich "+09: 00". (Zweites Mal) Dieses Ergebnis ist jedoch "+10: 00".
Wie Fall 1, jedoch weil die tz-Datenbank dies tatsächlich tut. Was die aktuellen Angelegenheiten betrifft, gab es vor einiger Zeit viel Lärm, als versucht wurde, die Sommerzeit für die Olympischen Spiele in Tokio einzuführen. Viele von Ihnen wissen es vielleicht anhand der damaligen Nachrichten, aber in Japan wurde die Sommerzeit tatsächlich zwischen 1949 und 1951 eingeführt. Das spiegelt sich in der tz-Datenbank wider.
――In der japanischen Standardzeit besteht bei altem Datum die Möglichkeit, dass eine Abweichung auftritt oder sich der Zeitzonenversatz ändert.
http://nowokay.hatenablog.com/entries/2015/01/09 https://ja.wikipedia.org/wiki/Tz_database http://www.mwsoft.jp/programming/other/time_mendoi.html https://qiita.com/sota2502/items/e8df68d9cfebd01af809
Recommended Posts