Discussion :

[grunt2000]

Bonjour,

Mes fonctions reçoivent une java.util.Date et ont besoin d'en extraire le jour du mois par getDay() afin de se servir du nombre que cette fonction retourne. Néanmoins, comme vous le savez, cette fonction est dépréciée.
(...et à mon avis, c'est une connerie. Les concepteurs de Java avaient mille autres choses utiles à faire que celle-là... Ou alors, il aurait fallu mettre les fonction de format dans Calendar également. On se retrouve avec deux objets distincts, incomplets chacun, pour gérer des dates...).

Bien sûr, je pourrais me tourner vers la classe java.util.Calendar. mais mon but n'est pas de faire un refactoring de mes prototypes de méthodes.

Comment puis-je obtenir proprement le jour d'une Date sans provoquer le warning de déprécation? (Bien entendu, je ne veux pas utiliser @SuppressWarnings("deprecated")).
- Je dois la convertir en Calendar puis prendre son jour? C'est dur pour les performances, non?
- Je dois faire un DateFormat, qui me donnera une String et la parser en Integer? C'est laid!

Je veux faire ceci, sans recevoir de warning de déprécation.
int jour = date.getDay();

Quelle est la façon propre et efficace de le faire?

En vous remerciant,

Grunt.

[tchize_]

La raison pour laquelle c'est déprécié, c'est qu'on ne peut pas fiablement extraire cette information avec le peu de données présentes dans Date. Pour avoir un jour, mois ou année, il faut un objet Date mais aussi un objet TimeZone. Car un même "java.util.Date" représente des jours / heures différentes dans chaque timezone. Et encore, en ne se basant que sur je Calendrier Grégorien, il existe aussi des tas d'autres Calendriers.

Donc, utilisez un Calendar, et passez ce Calendar à vos méthodes. Ou alors passez un date et un TimeZone à vos méthodes et reconstruisez le Calendar.

[adiGuba]

Salut,

- Je dois la convertir en Calendar puis prendre son jour? C'est dur pour les performances, non?

Oulà oui ! Il te faudra une machine de course pour faire cela !!!

Plus sérieusement c'est ce qui est indiqué dans la documentation. Pourquoi voudrais-tu faire autrement ?

Tu es en train de partir sur une solution bien crade qui risque d'être encore pire !

Calendar reste la seule et unique solution en standard !


Maintenant c'est vrai que l'API des Dates de Java n'est vraiment pas terrible, et si tu as de gros besoin là dessus tu pourrais opter pour une librairie externe bien plus complète comme JodaTime...


a++

[thelvin]

Salut,

- Je dois la convertir en Calendar puis prendre son jour? C'est dur pour les performances, non?

De toute façon, Date.getDate() fonctionne à peine autrement... L'implémentation de calendrier y est plus rapide, mais la différence n'est pas notable non plus.

[grunt2000]

Merci!

Donc, quand dans une fonction j'utilise conjointement formattage de date et extraction de ses valeurs numériques, j'utiliserai toujours Calendar?

Quel est l'intérêt, foncièrement, d'avoir deux objets distincts?

Si Calendar a la bonne implémentation vis à vis des timezones, pourquoi Date ne reprend t-elle pas la même? Eventuellement, en se voyant rajouter des constructeurs pour recevoir ce Timezone?

De plus, pourquoi s'il est celui à utiliser, tout est-il fait pour forcer le développeur à revenir au java.util.Date en permanence? Car le formattage des dates n'est pas accessible via un Calendar. Il peut y avoir mille vertueux qui recommandent l'emploi de Calendar, il y a dix mille programmeurs pour employer java.util.Date par grande commodité.

[tchize_]

Paradoxalement, l'intérêt de Date est qu'il est indépendant de la TimeZone.

Calendar, en permettant l'extraction des jours / heures / etc est lié à une TimeZone et un Calendrier. Bref à un point Géographique et un point culturel. Ainsi, nous somme le 24 janvier 2011 (Heure française) dans le Calendrier grégorien, mais nous sommes les 11 Janvier dans le Calendrier Julien.

Date est un absolu, c'est un moment, un point dans le temps, totalement indépendant d'un quelconque point Géographique ou de préférences locale. C'est l'idéal pour la plupart des fonctions de calcul et pour le stockage (un Date n'est jamais qu'un coque autour d'un long). C'est parce que ces méthodes n'ont justement pas besoin d'informations supplémentaires qu'elles continuent de prendre un objet de type Date (que tu peux extraire de ton Calendar).

Bref, Date est un "moment" et Calendar est la classe qui permet de le décortiquer.

Enfin, si, DateFormat accepte Calendar (méthode setCalendar()), bien qu'il n'utilise pas le moment situé à l'intérieur.

[thelvin]

Donc, quand dans une fonction j'utilise conjointement formattage de date et extraction de ses valeurs numériques, j'utiliserai toujours Calendar?

Ou au moins quelque chose de très proche, qui n'a pas de différence notable.

Quel est l'intérêt, foncièrement, d'avoir deux objets distincts?

Bonne question, mais tu te trompes de cible. C'est l'existence de Date que tu devrais contester, pas celle de Calendar.

Si Calendar a la bonne implémentation vis à vis des timezones, pourquoi Date ne reprend t-elle pas la même? Eventuellement, en se voyant rajouter des constructeurs pour recevoir ce Timezone?

Une Date, classe assez mal nommée, représente un instant dans le temps, mais sans s'intéresser à où sur Terre.

Si un parisen et un new-yorkais créaient un objet Date exactement à la même milliseconde, ces objets seraient 100% équivalents. Par contre, le parisien dirait qu'il est deux heures du mat' le 5 Janvier, et le new-yorkais dirait qu'il est vingt-deux heures le 4 Janvier. Pourtant ils parlent de la même Date.

Bref : une Date n'a pas de TimeZone, c'est à ça qu'elle sert, à ne pas avoir de TimeZone. Elle représente un instant universel. C'est pour ça que quand on veut l'écrire, on doit indiquer pour quelle TimeZone.

De plus, pourquoi s'il est celui à utiliser, tout est-il fait pour forcer le développeur à revenir au java.util.Date en permanence? Car le formattage des dates n'est pas accessible via un Calendar. Il peut y avoir mille vertueux qui recommandent l'emploi de Calendar, il y a dix mille programmeurs pour employer java.util.Date par grande commodité.

Raison inverse : un Calendar a une TimeZone et représente donc un instant dans le temps à un certain endroit.
C'est pratique pour faire des opérations calendaires, mais pas pour le reste.
Il est plus propre de garder les instants dans le temps dissociés de toute TimeZone, et de les attacher à une TimeZone seulement à un moment où ça a du sens, pas avant ni après.

Autrement dit, on manipule des Date sans TimeZone, et on les parse et les formate avec des DateFormat munis de TimeZones. Et on regarde leurs champs précis avec un Calendar muni de TimeZone.
Pour tout le reste (les mettre dans ordre, les stocker en mémoire,) on a pas besoin de TimeZone. Pas besoin => pas tout court.

C'est en tout cas le raisonnement qu'il y a derrière. Il est très discutable, et Joda-Time en tient un autre.

[adiGuba]

L'API de Date de Java n'est pas très "propre". Que ce soit java.util.Date (qui n'est pas immuable !) ou Calendar (d'utilisation hasardeuse).

De plus il lui manque certains concepts (durée, intervalle)

Ce n'est pas vraiment une API à prendre en exemple


a++

[itsmyr4bbit]

Je veux faire ceci, sans recevoir de warning de déprécation.
int jour = date.getDay();

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
GregorianCalendar calendar = new GregorianCalendar();
calendar.setTime(maDate);
int jour = calendar.get(Calendar.DAY_OF_MONTH);