DateFormat # setLenient (boolean) is a setting for ** loose date checking **. It is used in SimpleDateFormat etc. The default is true, which does not strictly check.
If you want a strict check, set false. [^ 1]
[^ 1]: It's the opposite of not being strict (don't design the boolean value to be reversed depending on how you think about it). Not loose. Not loose. Gachi. By the way, from Java 8, you can use Enumeration ResolverStyle with DateTimeFormatter. I am.
Reference: Open JDK DateFormat # setLenient (boolean), Oracle Java DateFormat # setLenient (boolean))
If you don't do a strict check, it will be interpreted as 3/1 even if it is 2/29 when it is not a leap year.
It's not very familiar in Japan, but it's said that it will be one hour earlier only in the summer that [^ 2]. In Eastern Time (EST / EDT) in New York, [^ 3] is set as daylight saving time from 2:00 am on the second Sunday in March to 2:00 am on the first Sunday in November, and this period is advanced by one hour. [^ 2]: Daylight saving time, daylight saving time, daylight saving time, sunmer time. It seems that it used to be in Japan. Depending on the area, it may be 30 minutes instead of 1 hour. [^ 3]: Until 2006, it was from 2:00 am on the first Sunday in April to 2:00 am on the last Sunday in October. It depends on the law.
private static void datechange(String date) {
SimpleDateFormat sdf = new SimpleDateFormat("yyyy/MM/dd HH:mm:ss");
sdf.setLenient(false); //Not loose
sdf.setTimeZone(TimeZone.getTimeZone("US/Eastern")); // EDT
try {
Date pdate = sdf.parse(date);
System.out.println(sdf.format(pdate));
} catch (Exception e) {
e.printStackTrace();
}
}
//Start of daylight saving time(1 hour ahead)
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
//End of daylight saving time(1 hour back)
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)
If you are doing a strict check setLenient (false) and the timezone is ʻEDT, parsing 2020/03/08 02:00:00will result injava.text.ParseException` ..
Even if it is not ʻEDT`, an error will occur if ** "1 hour skipped when daylight saving time comes" ** is specified in the time zone that considers daylight saving time.
In other words, 2020/03/08 02:00:00 does not exist in ** ʻEDT` **.
There is no error when returning for 1 hour. It's a little different from this story, but if you set the date as a unique key when going back one hour, it will be a unique constraint violation. Sorting doesn't work as expected either. [^ 4] [^ 4]: Let's hope that there is no system that registers the local time in the DB as a character string. (Usually it is a date type that is not affected by the time zone, UTC even if it is a character string, or epoch seconds as a numerical value)
Since we have specified a time that does not exist, the problem is not with the above specifications but with the original data and the capture process.
In this example, the cause was that the original data was JST instead of ʻEDT`. (Time zone inconsistency between original data [JST] and import process [EDT])
Recommended Posts