DateFormat # setLenient (boolean) est un paramètre pour la ** vérification de la date en vrac **. Il est utilisé dans SimpleDateFormat etc. La valeur par défaut est «true», ce qui ne vérifie pas strictement.
Si vous voulez une vérification stricte, définissez false. [^ 1]
[^ 1]: C'est le contraire de ne pas être exact (ne concevez pas la valeur booléenne pour qu'elle soit inversée en fonction de la façon dont vous y pensez). Pas lâche. Pas lâche. Gachi. D'ailleurs, à partir de Java 8, vous pouvez utiliser Enumeration ResolverStyle avec DateTimeFormatter. Je suis.
Référence: Open JDK DateFormat # setLenient (boolean), Oracle Java DateFormat # setLenient (boolean))
Si vous ne faites pas de contrôle strict, il sera interprété comme 3/1 même s'il est 2/29 alors que ce n'est pas une bonne année.
Ce n'est pas très familier au Japon, mais on dit que ce ne sera qu'une heure plus tôt que l'été que [^ 2]. À l'heure de l'Est (EST / EDT) à New York, [^ 3] est l'heure d'été de 2 h 00 le deuxième dimanche de mars à 2 h 00 le premier dimanche de novembre, et cette période est avancée d'une heure. [^ 2]: heure d'été, heure d'été, heure d'été, heure du soleil. Il semble que c'était au Japon. Selon la région, cela peut prendre 30 minutes au lieu de 1 heure. [^ 3]: Jusqu'en 2006, il était de 2 heures du matin le premier dimanche d'avril à 2 heures du matin le dernier dimanche d'octobre. Cela dépend de la loi.
private static void datechange(String date) {
SimpleDateFormat sdf = new SimpleDateFormat("yyyy/MM/dd HH:mm:ss");
sdf.setLenient(false); //Pas lâche
sdf.setTimeZone(TimeZone.getTimeZone("US/Eastern")); // EDT
try {
Date pdate = sdf.parse(date);
System.out.println(sdf.format(pdate));
} catch (Exception e) {
e.printStackTrace();
}
}
//Début de l'heure d'été(Avancez 1 heure)
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
//Fin de l'heure d'été(1 heure en arrière)
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)
Si vous avez une vérification stricte de setLenient (false) et que le fuseau horaire est ʻEDT, l'analyse 2020/03/08 02: 00: 00se traduira parjava.text.ParseException`. ..
Même si ce n'est pas ʻEDT`, une erreur se produira si ** "1 heure sautée quand l'heure d'été arrive" ** est spécifié dans le fuseau horaire qui considère l'heure d'été.
En d'autres termes, il n'y a pas de 2020/03/08 02: 00: 00 dans ** ʻEDT` **.
Il n'y a pas d'erreur lors du retour pendant 1 heure. C'est un peu différent de cette histoire, mais si vous définissez la date comme clé unique lorsque vous revenez en arrière d'une heure, vous violerez la contrainte unique. Le tri n'est pas comme prévu. [^ 4] [^ 4]: Espérons qu'il n'y a pas de système qui enregistre l'heure locale dans la base de données sous forme de chaîne de caractères. (Habituellement, il s'agit d'un type de date qui n'est pas affecté par le fuseau horaire, ou même s'il s'agit d'une chaîne de caractères, c'est UTC, ou c'est une époque numérique en seconde)
Puisque nous avons spécifié une heure qui n'existe pas, le problème n'est pas avec les spécifications ci-dessus mais avec les données d'origine et le processus de capture. Dans cet exemple, la cause était que les données d'origine étaient «JST» au lieu de «EDT». (Incohérence de fuseau horaire entre les données d'origine [JST] et le processus d'importation [EDT])
Recommended Posts