Quel est le problème avec Java Date et Heure de l'API?

Question

Très souvent je tombe sur des commentaires négatifs sur Java Date et d'autres de date-heure-classes associées. Être une .NET développeur, je ne peux pas entièrement (sans l'avoir utilisé) comprendre, ce qui est fait, le problème avec eux.

Quelqu'un peut-il éclairer sur ce point?

Answer 1

Ah, la Java Date classe. Peut-être l'un des meilleurs exemples de la façon de ne pas faire quelque chose dans n'importe quelle langue, n'importe où. Où dois-je commencer?

Lire la JavaDoc pourrait conduire à penser que les développeurs ont effectivement eu quelques bonnes idées. Il parle de la différence entre l'UTC et GMT à longueur de temps, malgré le fait que la différence entre les deux est fondamentalement secondes intercalaires (ce qui arrive assez rarement).

Toutefois, les décisions de conception vraiment jeter des déchets à toute pensée d'être un système bien conçu de l'API. Voici quelques-uns des favoris des erreurs:

• En dépit d'être conçu dans la dernière décennie du millénaire, le taux des années à deux chiffres depuis 1900. Il ya littéralement des millions de solutions faisant 1900+ (ou 1900-) dans le monde Java en tant que résultat de ce banal décision.
• Mois sont à zéro, indexé, pour répondre à la spectaculaire cas inhabituel d'avoir un tableau de mois et ne vivant pas avec treize élément de tableau, la première contenant un null. En conséquence, nous avons 0..11 (et aujourd'hui à 11 mois de l'année 109). Il y a un nombre similaire de ++ et -- sur les mois afin de convertir une chaîne de caractères.
• Ils sont mutables. Par conséquent, toutes les fois que vous voulez donner une date de retour (disons, comme une instance de la structure) vous avez besoin de retourner un clone de cette date au lieu de la date de l'objet lui-même (parce que sinon, les gens peuvent muter votre structure).
• L' Calendar, visant à "réparer" cette, rend en fait les mêmes erreurs. Ils sont toujours mutable.
• Date représente un DateTime, mais dans le but de s'en remettre à ceux dans SQL terre, il y a une autre sous - java.sql.Date, ce qui représente une seule journée (bien que, sans un fuseau horaire qui lui est associé).
• Il n'y a aucun TimeZones associé à un Date, et donc les distances (telles que "un jour") sont souvent représentés par un minuit-minuit (souvent dans certains arbitraire fuseau horaire)

Enfin, il est intéressant de noter que les secondes intercalaires généralement de corriger eux-mêmes contre une bonne horloge système qui est mis à jour avec ntp à moins d'une heure (voir les liens ci-dessous). La chance d'un système toujours en place et en cours d'exécution dans la mise en place de deux secondes intercalaires (tous les six mois au minimum, tous les quelques années pratiquement) est assez rare, surtout en considérant le fait que vous avez à redéployer les nouvelles versions de votre code de temps en temps. Même en utilisant un langage dynamique qui régénère les classes ou quelque chose comme une GUERRE, le moteur de polluer l'espace de classe et de s'enfuir de la permgen finalement.

Answer 2

La JSR-310, qui est prévu pour améliorer la Date de l'API pour Java 7, ne se justifie que dans l' original JSR comme suit:

2.5 Quel est le besoin de la communauté de Java seront abordées par le projet de cahier des charges?

Actuellement Java SE a deux distincts la date et l'heure des Api java.util.Date et java.util.Calendrier. Les deux Api sont constamment décrit comme difficile à l'utilisation par les développeurs Java sur les blogs et les des forums. Notamment, les deux utilisent un zéro-index pendant des mois, ce qui est à l'origine de nombreux des bugs. Le calendrier a également souffert de de nombreux bugs et problèmes de performances sur des années, principalement en raison de stocker des son état de deux façons différentes à l'interne.

Un classique de bug (4639407) a empêché certaines dates d'être créé en une Calendrier de l'objet. Une séquence de code pourrait être écrit, qui pourrait créer un date de quelques années mais pas dans d'autres, ayant pour effet d'empêcher certains les utilisateurs accèdent à leur correcte les dates de naissance. Ceci a été causé par la Calendrier de la classe ne permettant qu'à une daylight savings gain de temps d'une heure en été, historiquement, il a été plus de 2 heures autour de l'heure de la la seconde guerre mondiale. Bien que ce bug est maintenant corrigé, si à un certain moment dans l' l'avenir d'un pays a choisi d'introduire une daylight savings time gain de plus trois heures en été, puis l' Calendrier de la classe serait de nouveau cassé.

Le courant de l'API Java SE souffre également dans les environnements multi-threadés. Immuable classes sont connus pour être intrinsèquement thread-safe que leur état ne peut pas changer. Cependant, à la fois la Date et De calendrier sont mutables, ce qui nécessite les programmeurs d'envisager le clonage et filetage explicitement. En outre, l' l'absence de fil-sécurité DateTimeFormat n'est pas très connu et a été la cause de beaucoup de dur à traquer les problèmes de threading.

Ainsi que les problèmes avec les classes Java SE a pour datetime, il n'a pas de classes pour la modélisation d'autres les concepts. Non fuseau horaire dates ou temps, durée, périodes et les intervalles ont pas de représentation de classe dans Java SE. Ainsi, les développeurs souvent utiliser un int pour représenter un la durée de temps, avec javadoc la spécification de l'unité.

L'absence d'un programme exhaustif de la date et de l' modèle en temps aussi les résultats dans beaucoup de communes les opérations plus compliquées que ce qu'ils devrait être. Par exemple, le calcul de le nombre de jours entre deux dates il est particulièrement difficile de problème présent.

Cette JSR va aborder le problème d'une indiquer la date et l'heure de modèle, y compris les dates et les heures (avec et sans les fuseaux horaires), des durées et périodes de temps, les intervalles, la mise en forme et l'analyse.

Answer 3

• Date instances sont mutables, qui est presque toujours gênant.
• Ils ont une double nature. Ils représentent à la fois une heure et une date du calendrier. Il s'avère que c'est problématique quand on fait des calculs sur les dates.
• Les représentations numériques de données de calendrier sont contre-intuitif dans de nombreux cas. Par exemple: getMonth() est basé sur zéro, getYear() est de 1900 base (c'est à dire, l'année 2009 est représentée comme 109).
• Il leur manque beaucoup de fonctionnalités que vous attendez d'un Date classe.

Answer 4

Je ressens pour toi... comme un ancien .NET programmeur, j'ai posé les mêmes questions, le temps de l'API .NET (timespans, la surcharge d'opérateur) est très pratique.

Tout d'abord, pour créer une date spécifique, vous utilisez une API obsolètes, ou:

Calendar c = Calendar.getInstance();
c.set(2000, 31, 12)

Pour soustraire un jour de vous faire du mal, des choses comme

Date firstDate = ...
Calendar c = Calendar.getInstance();
c.setTime(fistDate);
c.add(Calendar.DATE,-1);
Date dayAgo = c.getTime();

ou pire

Date d = new Date();
Date d2 = new Date(d.getTime() - 1000*60*60*24);

Pour savoir de combien de temps s'est écoulé entre deux dates (jours / semaines / mois)... c'est encore pire

Cependant DateUtils d'apache (org.apache.commons.lang.time.DateUtils) offre certaines des méthodes pratiques et je me suis retrouvé à l'aide seulement d'eux ces derniers temps

Comme Brabster écrit, Joda Time est aussi une bonne bibliothèque externe, mais apache semble plus "commun" qu'autre chose...

Answer 5

Je trouve Java Date de l'API utilisable, pour être honnête. La plupart des questions que j'ai vu et entendu à propos concernent le niveau de verbosité, la nécessité d'impliquer plusieurs classes à faire quelque chose d'utile (Calendar, Date, DateFormat/SimpleDateFormat) et le manque de moyens simples accesseurs comme getDayOfWeek().

Joda Time est respectée alternative API en Java, et dans le Pourquoi Joda section du Temps, il donne plus d'arguments pour expliquer pourquoi il est une alternative viable qui pourrait être d'intérêt.