web-dev-qa-db-fra.com

Utilisation recommandée pour Joda-Time DateMidnight

Le javdoc pour LocalDate#toDateMidnight se lit comme suit:

À partir de la version 1.5, il est recommandé d'éviter DateMidnight et d'utiliser toDateTimeAtStartOfDay () à la place en raison de l'exception détaillée au dessous de.

Cette méthode lève une exception si le fuseau horaire par défaut bascule à l'heure d'été à minuit et cette date locale représente cette date de basculement. Le problème est qu’il n’existe pas de temps comme minuit à la date requise et, à ce titre, une exception est levée.

Le fait que minuit n’existe pas dans certains fuseaux horaires semble être une raison suffisante pour éviter d’utiliser entièrement DateMidnight (en supposant que votre code n’utilise pas un fuseau horaire fixe dont on sait qu’il ne présente pas cette situation DST et n’aura jamais besoin d’utiliser des fuseaux horaires différents dans l’enregistrement. l'avenir).

Cependant, DateMidnight n'est pas obsolète et il n'y a pas de recommandation ou d'avertissement similaire dans le javadoc pour la classe DateMidnight elle-même. De plus, le constructeur DateMidnight accepte avec joie un instant et un fuseau horaire tels que minuit n’existe pas le jour donné, au lieu de lancer une IllegalArgumentException telle que LocalDate#toDateMidnight. La DateMidnight résultante se comporte comme une DateTime avec l'heure au début de la journée.

Quand minuit n’existe pas un jour donné, pourquoi LocalDate#toDateMidnight lève-t-il une exception alors que le constructeur DateMidnight ne le fait pas? Quel est le cas d'utilisation recommandé pour DateMidnight le cas échéant?

javadatejodatime
39
oby1

Il n'y a pas de bonne raison d'utiliser DateMidnight. LocalDate est la meilleure option. C’est parce que minuit ne se produit pas une fois par an dans certains fuseaux horaires, ce qui gâche complètement la convivialité de la classe et crée des bogues dans les applications.

Le constructeur a été corrigé pour éviter le pire problème. Cependant, voir un objet DateMidnight avec la valeur en millisecondes interne pointant à 01:00 n'est pas tout à fait génial.

43
JodaStephen

new DateTime () . withTimeAtStartOfDay () est recommandé. 

32
Jerome Anthony

Ou mieux, utilisez la méthode LocalDatetoDateTimeAtStartOfDay directement pour contourner la création de l'objet DateTime (en relation avec réponse ci-dessus ).

new LocalDate().toDateTimeAtStartOfDay( myDateTimeZone )
8
coolersport

Voici une solution plus simple qui vérifiera si le dateTime a lieu à minuit heure locale  

private boolean isAtMidnight(org.joda.time.DateTime dateTime) {
   return dateTime.toLocalDateTime().getMillisOfDay() == 0;
}
0
Woody

Regardez l'exception que j'avais dans mon code 

Illegal instant due to time zone offset transition (daylight savings time 'gap'): 2015-03-27T00:00:00.000 (Asia/Amman)
    org.joda.time.IllegalInstantException: Illegal instant due to time zone offset transition (daylight savings time 'gap'): 2015-03-27T00:00:00.000 (Asia/Amman)

Maintenant je l'ai résolu en utilisant 

LocalDate currentDate=new LocalDate();
someMethodSetsTheDate(currentDate.toDateTimeAtStartOfDay().toDate());

Au lieu de

someMethodSetsTheDate(new DateMidnight(date.getYear(), date.getMonthOfYear(), date.getDayOfMonth()).toDate());

Ma recommandation est maintenant d'utiliser .toDateTimeAtStartOfDay () Pour éviter des exceptions similaires.

S'il vous plaît n'hésitez pas à modifier ma réponse Merci

0
shareef