Discussion :

[biboo_]

Salut à tous,

Je suis face à un gros problème concernant la méthode "set" de la classe Calendar. En effet, je manipule des dates dans une application en J2EE, et en exécutant le code, j'obtients un résultat différent entre mon serveur Weblogic 10 (en local, tournant sous windows XP) et un serveur Weblogic 10 distant (tournant sous Solaris 10).

Voici la portion de code incriminée (en gras) (faites pas attention à la logique du code, je ne fais que passer derrière du code qui ne m'appartient pas ) :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12

// compare = Wed Feb 02 16:42:54 CET 2011

compare.add(Calendar.DAY_OF_YEAR, 7);
LOG.debug("compare.add(Calendar.DAY_OF_YEAR.. = "+compare.getTime());

compare.set(Calendar.DAY_OF_WEEK, Calendar.SUNDAY);
LOG.debug("compare.set(Calendar.DAY_OF_WEEK.. = "+compare.getTime());

compare.add(Calendar.DAY_OF_YEAR, -7);
LOG.debug("compare.add(Calendar.DAY_OF_YEAR.. = "+compare.getTime());

Et le résultat dans les logs :

- En local :

getDuree() : compare.add(Calendar.DAY_OF_YEAR.. = Wed Feb 09 16:42:54 CET 2011
getDuree() : compare.set(Calendar.DAY_OF_WEEK.. = Sun Feb 13 16:42:54 CET 2011
getDuree() : compare.add(Calendar.DAY_OF_YEAR.. = Sun Feb 06 16:42:54 CET 2011

- Sur mon serveur Weblo distant :

getDuree() : compare.add(Calendar.DAY_OF_YEAR.. = Wed Feb 09 16:42:17 CET 2011
getDuree() : compare.set(Calendar.DAY_OF_WEEK.. = Sun Feb 06 16:42:17 CET 2011
getDuree() : compare.add(Calendar.DAY_OF_YEAR.. = Sun Jan 30 16:42:17 CET 2011

=> Comme vous pouvez le constater, sur le serveur distant (tournant sous Solaris), il y a une semaine de différence.
La bonne valeur est celle sur mon serveur local, évidemment.

Question : Quelqu'un aurait-il une idée de la cause de cette différence de comportement, a priori venant de la méthode SET?

Infos complémentaires : le serveur distant est bien à la même date et au même TimeZone que mon serveur en local, même "Locale" (FR).

En espérant avoir été clair, merci d'avance de votre aide.

[adiGuba]

Salut,


Tu es sûr pour le TimeZone/Locale ?
Attention aux pays de la Locale qui pourrait également avoir un impact (du fr_FR ce n'est pas pareil que du fr_CA par exemple).


a++

[thelvin]

Infos complémentaires : le serveur distant est bien à la même date et au même TimeZone que mon serveur en local, même "Locale" (FR).

Ouais ben ça, au lieu de le dire il vaudrait mieux le prouver.

- Pour la TimeZone, en effet, pas trop de doute : les deux indiquent CET par défaut.

- Pour la Locale, tout se comporte comme si dimanche était le dernier jour de la semaine sur la machine locale, et le premier jour de la semaine sur la machine distante.
Un signe flagrant de locales différentes.

[tchize_]

Quand vous créez des objets Calendar pour manipuler des jours de la semaine, des heures pouvant passer le décalage été / hiver ou tout autre données spécifique à l'environnement, TOUJOURS leur donner ue timezone et un Locale explicite!

[biboo_]

Ouais ben ça, au lieu de le dire il vaudrait mieux le prouver.

- Pour la TimeZone, en effet, pas trop de doute : les deux indiquent CET par défaut.

- Pour la Locale, tout se comporte comme si dimanche était le dernier jour de la semaine sur la machine locale, et le premier jour de la semaine sur la machine distante.
Un signe flagrant de locales différentes.

Salut,

Effectivement je me pense m'être fait avoir. J'ai loggé la locale mais c'est celle du client (il me retourne FR).
Seulement, sur le serveur Solaris, la commande "locale" LC_TIME" me retourne "en_US" (j'imagine que c'est cet attribut qui compte).

[thelvin]

Salut,

Effectivement je me pense m'être fait avoir. J'ai loggé la locale mais c'est celle du client (il me retourne FR).
Seulement, sur le serveur Solaris, la commande "locale" LC_TIME" me retourne "en_US" (j'imagine que c'est cet attribut qui compte).

En fait, au démarrage, la JVM détermine une Locale par défaut, une seule, et elle s'en sert pour tout : langue, pays, formats de nombres et dates, premier jour de la semaine...

Une Locale n'est composée que de 3 composants : pays, langue, variante (variante est inutilisée la plupart du temps.)
Autrement dit, le jour de la semaine, le format des nombres, ce n'est pas stocké dans la Locale : c'est déduit du pays et de la langue indiqués par la Locale.

Sous Unix, la Locale par défaut est déterminée par $LANG, pas par $LC_TIME (qui ne s'occupe que des questions de temps.)
En tout cas par défaut, mais on peut démarrer une JVM en lui indiquant une Locale par défaut.
Le seul moyen d'être sûr, c'est de regarder ce que renvoie

Code :

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

Locale.getDefault()

ou

Code :

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

Calendar.getInstance().getFirstDayOfWeek()

(en sachant que 1 est le dimanche, 2 est le lundi...)

Note : en fait, ça c'est la méthode pour comprendre d'où venait le problème.
Mais pour le résoudre, il faut faire ce que dit tchize_ : forcer le premier jour de la semaine avec setFirstDayOfWeek(Calendar.MONDAY)
et forcer aussi la time zone, pour les mêmes raisons.

[tchize_]

Mais pour le résoudre, il faut faire ce que dit tchize_ : forcer le premier jour de la semaine avec setFirstDayOfWeek(Calendar.MONDAY)

Ne me faites pas dire ce que je n'ai pas dit, s'il vous plaît.

[thelvin]

My bad.
Je voulais dire, la solution c'est celle de tchize_, en l'occurrence forcer TimeZone et Locale.
(Oui dans ma tête, forcer la Locale et forcer le premier jour de la semaine sont des notions voisines.)
(Oui, je suis bizarre.)