DateFormat # setLenient (boolean) ist eine Einstellung für ** Prüfung auf lose Daten **. Es wird in SimpleDateFormat usw. verwendet. Der Standardwert ist "true", was nicht streng überprüft wird.
Wenn Sie eine strenge Prüfung wünschen, setzen Sie "false". [^ 1]
[^ 1]: Es ist das Gegenteil von Ungenauigkeit (entwerfen Sie den Booleschen Wert nicht so, dass er umgekehrt wird, je nachdem, wie Sie darüber denken). Nicht locker. Nicht locker. Gachi. Unter Java 8 können Sie übrigens Enumeration ResolverStyle mit DateTimeFormatter verwenden. Ich bin.
Referenz: JDK DateFormat # setLenient (boolean) öffnen, Oracle Java DateFormat # setLenient (boolean))
Wenn Sie keine strenge Prüfung durchführen, wird dies als 3/1 interpretiert, auch wenn es 2/29 ist, wenn es kein gutes Jahr ist.
Es ist in Japan nicht sehr bekannt, aber es wird gesagt, dass es nur im Sommer eine Stunde früher sein wird (https://ja.wikipedia.org/wiki/%E5%A4%8F%E6%99%82%E9%96%93 ) [^ 2]. In der östlichen Zeit (EST / EDT) in New York [^ 3] ist die Sommerzeit von 2:00 Uhr am zweiten Sonntag im März bis 2:00 Uhr am ersten Sonntag im November, und dieser Zeitraum wird um eine Stunde vorverlegt. [^ 2]: Sommerzeit, Sommerzeit, Sommerzeit, Sonnenzeit. Es scheint, dass es früher in Japan war. Je nach Region können es 30 Minuten statt 1 Stunde sein. [^ 3]: Bis 2006 war es von 2:00 Uhr am ersten Sonntag im April bis 2:00 Uhr am letzten Sonntag im Oktober. Es kommt auf das Gesetz an.
private static void datechange(String date) {
SimpleDateFormat sdf = new SimpleDateFormat("yyyy/MM/dd HH:mm:ss");
sdf.setLenient(false); //Nicht locker
sdf.setTimeZone(TimeZone.getTimeZone("US/Eastern")); // EDT
try {
Date pdate = sdf.parse(date);
System.out.println(sdf.format(pdate));
} catch (Exception e) {
e.printStackTrace();
}
}
//Beginn der Sommerzeit(1 Stunde vorrücken)
datechange("2020/03/08 01:59:59"); // OK
datechange("2020/03/08 02:00:00"); // NG: ParseException
datechange("2020/03/08 02:00:01"); // NG: ParseException
datechange("2020/03/08 02:59:59"); // NG: ParseException
datechange("2020/03/08 03:00:00"); // OK
//Ende der Sommerzeit(1 Stunde zurück)
datechange("2020/11/01 01:59:59"); // OK
datechange("2020/11/01 02:00:00"); // OK
datechange("2020/11/01 02:00:01"); // OK
datechange("2020/11/01 02:59:59"); // OK
datechange("2020/11/01 03:00:00"); // OK
java.text.ParseException: Unparseable date: "2020/03/08 02:00:00"
at java.text.DateFormat.parse(DateFormat.java:357)
Wenn Sie "setLenient (false)" streng prüfen und die Zeitzone "EDT" ist, führt das Parsen von "2020/03/08 02: 00: 00" zu "java.text.ParseException" ..
Auch wenn es sich nicht um "EDT" handelt, tritt ein Fehler auf, wenn in der Zeitzone, die die Sommerzeit berücksichtigt, ** "1 Stunde zur Sommerzeit übersprungen" ** angegeben ist.
Mit anderen Worten, ** EDT hat nicht 2020/03/08 02: 00: 00 **.
Bei der Rückkehr für 1 Stunde tritt kein Fehler auf. Es unterscheidet sich ein wenig von dieser Geschichte, aber wenn Sie das Datum als eindeutigen Schlüssel festlegen, wenn Sie eine Stunde zurückgehen, ist dies eine eindeutige Verletzung der Einschränkungen. Die Sortierung ist nicht wie erwartet. [^ 4] [^ 4]: Hoffen wir, dass es kein System gibt, das die Ortszeit in der Datenbank als Zeichenfolge registriert. (Normalerweise handelt es sich um einen Datumstyp, der nicht von der Zeitzone beeinflusst wird, oder selbst wenn es sich um eine Zeichenfolge handelt, handelt es sich um UTC oder um eine numerische Epochensekunde.)
Da wir eine Zeit angegeben haben, die nicht existiert, liegt das Problem nicht bei den obigen Spezifikationen, sondern bei den Originaldaten und dem Erfassungsprozess. In diesem Beispiel war die Ursache, dass die Originaldaten "JST" anstelle von "EDT" waren. (Zeitzoneninkonsistenz zwischen Originaldaten [JST] und Importprozess [EDT])
Recommended Posts