[JodaTime] Création de date avec semaine et année

Version imprimable

bonjour

je désire créer une date a partir d'une semaine et d'une année.
Code:

1 2 3 4 5 6 DateTime dt = new DateTime(); dt.withWeekyear(29); dt.withYear(2011); System.out.println("dt " + dt.getWeekOfWeekyear() + " " + dt.getYear());
avec ce code j'obtiens à l'affichage: 16 2012 soit les la semaine et l'année en cours

comment faire pour obtenir 29 2011?

une idée?

Ouh là là le petit coquin qui n'a pas lut la doc ! :nono:

Dans la doc il est écrit que DateTime est un objet immuable.
Immuable ça veut dire qu'on ne peut pas changer .. eh oui !

donc : inutile d'essayer de lui modifier sa semaine ou son année.
Ada Lovelace, David Hilbert, Alan Turing et John von Neumann n'ont pas voulu essayer ... c'est dire la difficulté !

En revanche, dans sa grande bonté, le Dieu Joda a prévu une autre classe : MutableDateTime :salive:
Ce qui nous donne :
Code:

1 2 3 4 5 MutableDateTime dt = new MutableDateTime(); dt.setWeekOfWeekyear(29); dt.setYear(2011); System.out.println("dt " + dt.getWeekOfWeekyear() + " " + dt.getYear());
et tu obtiens bien :

Citation:

dt 29 2011

Voilà, c'était la déconnade du samedi.

Bon, allez @lequebecois79 c'est pas grave, ;) moi aussi j'avais pas mal cherché pourquoi
mon DateTime ne bougeais pas avant de trouver l'existence de l'autre classe !

Et je ne vois pas bien pourquoi Joda a créé une classe immuable et l'autre non.

21/04/2012, 18h17
thelvin

Citation:

Envoyé par Népomucène

Et je ne vois pas bien pourquoi Joda a créé une classe immuable et l'autre non.

Parce qu'une date, c'est une date, c'est pas mardi à un moment et lundi trois appels de méthodes plus tard. Une date ça sert à indexer des Map, ou à être gardé comme collection dans un Set.
Et ces machins-là, ça doit être immutable.

Mais n'avoir que des objets immutables, c'est emmerdant quand on a besoin de construire sur un calendrier dont on change tout le temps les données : créer soixante nouveaux objets DateTime à chaque fois qu'on veut en garder trois, c'est pas terrible terrible. Pour ce cas-là, ont été ajoutées les versions mutables. À utiliser pour construire les immutables.
21/04/2012, 19h11
Népomucène

Citation:

Parce qu'une date, c'est une date, c'est pas mardi à un moment et lundi trois appels de méthodes plus tard

moui, moui, moui ... certes, bien sûr.

Je vais faire un parallèle avec les dates que j'utilise dans mes bases de données.
Les dates de factures, d'écritures comptables, etc sont stockées dans des ~~champs~~ colonnes(*) de type "DateTime".
Ces dates sont toutes modifiables avec l'instruction "UPDATE ..." donc pas de blocage du point de vue du SGBD.

Mais je vais bien sûr ajouter le verrouillage qui va bien (Trigger, vérification dans l'application client, etc.)
pour que mes dates de factures ne soient jamais modifiées une fois que le document a été validé.
Le même outil de programmation (champ date) me sert donc indifféremment pour des dates modifiables ou non.

Donc je continue de penser qu'il aurait été possible de faire avec une seule classe mutable.

(*) il faut utiliser le mot colonnes sinon notre ami SqlPro va me faire les gros yeux ;)
21/04/2012, 19h53
thelvin

Oui, une BDD est rarement en lecture seule pour absolument tout le monde. Pas seulement les dates, on peut aussi mettre à jour les entiers et les textes. Integer et String sont pourtant immutables.

Une BDD est un stockage, pas un espace de programmation. Du moins en principe, et puis même quand on programme une BDD, les données volatiles et l'espace de stockage durable sont deux choses différentes qui n'ont aucun lien l'une avec l'autre.

C'est comme je l'ai dit : une date doit être immutable, parce qu'une date on s'en sert pour indexer des Map ou les collectionner dans un Set. Or ce qu'on utilise pour ça doit être immutable. Puisque ça ne doit pas muter.

Citation:

Donc je continue de penser qu'il aurait été possible de faire avec une seule classe mutable.

Bien sûr que ça aurait été possible, c'est d'ailleurs ce que fait Java de base : java.util.Date est mutable. (Bon, ça ne permet pourtant pas de construire une Date correctement. Pour ça il faut un Calendar. java.util.Date a plusieurs défauts de conception, dont celui-ci.)
Il est possible de le faire, simplement il ne faut pas le faire.
21/04/2012, 20h59
Népomucène

Citation:

Il est possible de le faire, simplement il ne faut pas le faire

ça c'est une belle expression, élégante, qui exprime bien pourquoi il faut de la rigueur dans la conception.
(exemple d'absence de rigueur pour moi : ne rien mettre rien dans les catchs des exceptions !)

Bon, naturellement, je suis d'accord avec toi sur le but final de l'opération :
une fois qu'on a placé une date dans une map ou une table de SBGD alors ça ne doit plus bouger.

Mais comme j'ai l'habitude de décider moi-même de ce qui bouge ou pas ...
Je suis probablement susceptible mais DateTime immuable pour moi c'était un peu
comme si Joda me disait : "écoute petit, comme tu ne sais pas programmer, je vais te bloquer de ce côté là ..."

Bon, @thelvin merci pour ton avis (rigoureux) sur lequel je vais méditer (à partir de lundi)
maintenant il faut que je réfléchisse pour qui je vais voter demain :lol:

bonne soirée à tous
22/04/2012, 01h33
thelvin

Citation:

Envoyé par Népomucène

une fois qu'on a placé une date dans une map ou une table de SBGD alors ça ne doit plus bouger.

Pourquoi ?
C'est juste que dans le cas d'une Map, si on veut changer l'index, il ne faut pas muter l'index. Il faut le retirer, puis réinsérer dans le bon.
C'est pas du tout une question de propreté ni de conception, c'est purement technique : est-ce que ça marche, oui ou non ? Muter un index, ça ne marche pas. Gérer les index autrement qu'en les mutant, ça marche. On peut pas faire plus pragmatique.

Citation:

Envoyé par Népomucène

Je suis probablement susceptible mais DateTime immuable pour moi c'était un peu
comme si Joda me disait : "écoute petit, comme tu ne sais pas programmer, je vais te bloquer de ce côté là ..."

Non, c'est exactement ça, et c'est exactement ce qu'il faut faire, et c'est ce que font les bibliothèques bien conçues.

Le niveau du programmeur n'est pas important, ce qui est important c'est que la mutabilité est source potentielle d'erreur. Certaines sources potentielles d'erreur peuvent être supprimées, d'autres ne le peuvent pas. En l'occurrence, celle-ci peut être supprimée.

Ne pas supprimer une source d'erreur supprimable, est en soi une erreur, par tautologie.

Autrement dit, dans le cas présent, la manière correcte de ne pas se tromper, c'était de fournir une classe date immutable.