la meilleure façon d'utiliser le nouveau code (si votre police autorise le code de tiers) est d'utiliser la bibliothèque Joda Time .

les deux, Date et calendrier , ont tellement de problèmes de conception que ni l'une ni l'autre ne sont de bonnes solutions pour le nouveau code.

• Date et Calendar sont vraiment le même concept fondamental (tous deux représentent un instant in time et sont enveloppants autour d'une valeur sous-jacente long ).

• on pourrait soutenir que Calendar est en fait encore plus cassé que Date est, car il semble offrir des faits concrets sur des choses comme le jour de la semaine et l'Heure de la journée, alors que si vous changez sa propriété timeZone , le béton se transforme en blanc-manger! Ni l'un ni l'autre des objets ne sont vraiment utiles comme un magasin de Année-Mois-Jour ou Heure-de-jour pour cette raison.

• utilisez Calendar seulement comme calculatrice qui, lorsqu'elle est donnée Date et TimeZone objets, fera des calculs pour vous. Évitez son utilisation pour la saisie de propriété dans une application.

• utilisez SimpleDateFormat avec TimeZone et Date pour générer des chaînes d'affichage.

• si vous vous sentez aventureux utilisez Joda-Time, bien qu'il soit inutilement compliqué IMHO et sera bientôt remplacé par le JSR-310 date API dans tous les cas.

• j'ai répondu avant qu'il n'est pas difficile de rouler votre propre classe YearMonthDay , qui utilise Calendar sous la hotte pour le calcul de la date. J'ai été rétrogradé pour la suggestion mais je crois toujours qu'elle est valide parce que Joda-Time (et JSR-310 ) sont vraiment trop compliquées pour la plupart des cas d'utilisation.

Date est le meilleur pour stocker un objet date. C'est le persisté, la Sérialisé ...

est le meilleur pour manipuler les Dates.

Note: Nous préférons aussi parfois java.lang.Long over Date, parce que Date est mutable et donc pas sûr de fil. Sur un objet Date, utilisez setTime() et getTime() pour basculer entre les deux. Par exemple, une Date constante dans l'application (Exemples: le zéro 1970/01/01, ou une application END_OF_TIME que vous définissez à 2099/12/31 ; ceux-ci sont très utiles pour remplacer les valeurs nulles comme l'Heure de début et l'Heure de fin, surtout quand vous les persistez dans la base de données, car SQL est si particulier avec nulls).

j'utilise généralement la Date si possible. Bien qu'il soit mutable, les mutants sont en fait dépréciés. En fin de compte, il enroule essentiellement un long qui représenterait la date/heure. À l'inverse, j'utiliserais des calendriers si je devais manipuler les valeurs.

vous pouvez penser à cela de cette façon: vous n'utilisez StringBuffer que lorsque vous avez besoin d'avoir des chaînes que vous pouvez facilement manipuler et ensuite les convertir en Chaînes en utilisant la méthode toString (). De la même manière, je ne l'utilise Calendrier si je dois manipuler des données temporelles.

pour les bonnes pratiques, j'ai tendance à utiliser autant que possible des objets immuables en dehors du modèle de domaine . Il réduit considérablement les risques d'effets secondaires et il est fait pour vous par le compilateur, plutôt que d'un test JUnit. Vous utilisez cette technique en créant des champs final privé dans votre classe.

et revenons à L'analogie de StringBuffer. Voici un code qui vous montre comment convertir entre le calendrier et la Date

String s = "someString"; // immutable string
StringBuffer buf = new StringBuffer(s); // mutable "string" via StringBuffer
buf.append("x");
assertEquals("someStringx", buf.toString()); // convert to immutable String

// immutable date with hard coded format.  If you are hard
// coding the format, best practice is to hard code the locale
// of the format string, otherwise people in some parts of Europe
// are going to be mad at you.
Date date =     new SimpleDateFormat("yyyy-MM-dd", Locale.ENGLISH).parse("2001-01-02");

// Convert Date to a Calendar
Calendar cal = Calendar.getInstance();
cal.setTime(date);

// mutate the value
cal.add(Calendar.YEAR, 1);

// convert back to Date
Date newDate = cal.getTime();

// 
assertEquals(new SimpleDateFormat("yyyy-MM-dd", Locale.ENGLISH).parse("2002-01-02"), newDate);

Date s doivent être utilisés comme points immuables dans le temps; Calendar s sont mutables, et peuvent être transmis et modifiés si vous avez besoin de collaborer avec d'autres classes pour venir avec une date finale. Considérez - les comme String et StringBuilder et vous comprendrez comment je considère qu'ils devraient être utilisés.

(et oui, je sais que la Date n'est pas techniquement immuable, mais l'intention est qu'elle ne soit pas mutable, et si rien n'appelle la méthodes dépréciées alors il en est ainsi.)

avec Java 8, le nouveau java.le paquet temporel doit être utilisé.

sont immuables, les fuseaux horaires et l'économie de lumière de jour sont pris en compte.

vous pouvez créer un ZonedDateTime objet d'un ancien java.util.Date objet comme ceci:

    Date date = new Date();
    ZonedDateTime zonedDateTime = date.toInstant().atZone(ZoneId.systemDefault());

j'ai toujours l'avocat Joda-time . Voici pourquoi.

1. L'API est cohérente et intuitive. Contrairement à la java.util.Date / Calendrier APIs
2. il ne souffre pas de problèmes de threading, contrairement à java.texte.SimpleDateFormat etc. (J'ai vu de nombreux problèmes de client liés à ne pas se rendre compte que la date/heure standard formatage n'est pas thread-safe)
3. c'est la base de la nouvelle API Date/heure Java ( JSR310 , prévue pour Java 8. Vous utiliserez donc des API qui deviendront des API Java core.

tl; dr

conseiller le courant de la "meilleure pratique" autour de Date et Calendar

est-il préférable de toujours favoriser Calendar plutôt que Date

évitez ces classes héritées entièrement. Utilisez java.heure classes à la place.

• Pour un moment UTC , l'utilisation Instant
  
  (l'équivalent moderne de Date )
• pour un moment dans un particulier fuseau horaire , utiliser ZonedDateTime
  
  (l'équivalent moderne de GregorianCalendar )
• pour un moment dans un particulier offset-from-UTC , utiliser OffsetDateTime
  
  (pas d'équivalent dans les classes legacy)
• Pour une date en temps (pas un instant) avec de temps inconnu de la zone ou de décalage, l'utilisation LocalDateTime
  
  (pas d'équivalent dans les classes héritées)

détails

Le Réponse en Ortomala Lokni est en droit de proposer à l'aide de la moderne de java.temps classes plutôt que le vieil héritage gênant classes de date-heure ( Date , Calendar , etc.). Mais cette Réponse suggère la mauvaise classe comme équivalent (voir mon commentaire sur cette Réponse).

utilisant java.time

La java.les classes de temps sont une vaste amélioration par rapport à l'héritage date-heure classes, nuit et jour différence. Les anciennes classes sont mal conçues, déroutantes et gênantes. Dans la mesure du possible, évitez les anciennes classes. Mais quand vous avez besoin de convertir vers/à partir de l'ancienne / nouvelle, vous pouvez le faire en appelant les nouvelles méthodes Ajouter aux classes ancienne .

pour beaucoup plus d'informations sur la conversion, voir ma réponse et le diagramme nifty à une autre Question, convertir java.util.La Date de ce "java.temps" type? .

Searching Stack Overflow donne des centaines d'exemples de Questions et de réponses sur l'utilisation de java.temps. Mais voici un rapide résumé.

Instant

Obtenir à l'heure actuelle, avec un Instant . La classe Instant représente un moment sur la ligne de temps dans UTC avec une résolution de nanosecondes (jusqu'à neuf (9) chiffres d'une fraction décimale).

Instant instant = Instant.now();

ZonedDateTime

pour voir que même moment simultané à travers la lentille d'une région particulière wall-clock time , appliquer un fuseau horaire( ZoneId ) pour obtenir un ZonedDateTime .

fuseau horaire

spécifier un nom du fuseau horaire approprié dans le format de continent/region , tel que America/Montreal , Africa/Casablanca , ou Pacific/Auckland . N'utilisez jamais l'abréviation de 3-4 lettres comme EST ou IST car ils sont pas vrai fuseaux horaires, non standardisé, et même pas unique(!).

ZoneId z = ZoneId.of( "America/Montreal" );
ZonedDateTime zdt = instant.atZone();

Offset

un fuseau horaire est l'histoire d'une région de changements dans son offset-from-UTC . Mais parfois on ne vous donne qu'un décalage sans la pleine zone. Dans ce cas, utilisez la classe OffsetDateTime .

ZoneOffset offset = ZoneOffset.parse( "+05:30" );
OffsetDateTime odt = instant.atOffset( offset );

Utilisation d'un fuseau horaire est préférable par rapport à l'utilisation d'un simple décalage.

LocalDateTime

le "Local" dans les classes Local… signifie toute "localité 1519990920", et non une localité particulière. Si le nom peut être contre-intuitif.