Discussion :

[gronono]

Bonjour,

J'ai constaté un bug très spécifique sur les fuseaux horaires en Java sous Windows.

Le programme tourne en Nouvelle-Calédonie donc en GMT+11.
En Nouvelle-Calédonie, il n'y a actuellement pas d'heure d'été.

Lorsqu'on exécuté le programme, sur certaines dates, un décalage de moins une heure se produisait. Le 01/01/1978 fait parmi des dates concernées.

Sur le serveur, voici la date récupérée (DateFormat utilisé : "dd/MM/yyyy HH:mm:ss Z zzzz)

01/01/1978 00:00:00 +1200 Heure d'été de Nouvelle-Calédonie

Tandis que sur le client la même date est :

31/12/1977 23:00:00 +1100 Heure des îles Salomon

Le fuseau horaire Nouvelle-Calédonie et le même que celui des îles Salomon.

Après quelques recherches, il s'avère que l'heure d'été était actif en Nouvelle-Calédonie en 78. Par contre :

Code :

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

1
2
 
System.out.println("DST 01/01/1978 = " + TimeZone.getDefault().inDaylightTime(new GregorianCalendar(1978, Calendar.JANUARY, 1).getTime()));

M'affiche true sous Linux avec JRE 1.5.0_06, mais false sous Windows (même version de JRE)

Donc j'aimerai savoir si la jvm s'appuie sur le système pour déterminer cette info? Si oui pourquoi sun fait des maj de time zone régulièrement ?

A+
Gronono

[tchize_]

la jvm s'appuie sur l'os pour déterminer la timezone courante. Par contre, tous ses calculs de date sont purement internes.

[gronono]

La timezone est la bonne dans les deux jvms (client et serveur). C'est GMT+11.

Par contre lorsque ma date (avec la TZ à GMT+12) arrive (via RMI) coté client, elle est convertie en GMT+11. Donc il y a une perte d'une heure.

Normalement, elle devrait être convertie en GMT+12 puisque en 1978 l'heure d'été était active.

A+
Gronono

[tchize_]

La timezone est la bonne dans les deux jvms (client et serveur). C'est GMT+11.

Par contre lorsque ma date (avec la TZ à GMT+12) arrive (via RMI) coté client, elle est convertie en GMT+11. Donc il y a une perte d'une heure.

C'est pas comme çà que çà marche, la date, en elle même, n'a pas de timezone. Elle n'est donc pas convertie lors du passage sur RMI. C'est uniquement lors de sa convertion de et vers des strings que la timezone est utilisée.

De plus, GMT+11 en lui même ne défini pas entièrement une timezone. Comme tu l'as précisé dans ton premier post, sur une des machines la timezone est "Nouvelle-Calédonie" et sur l'autre la timezone est "îles Salomon".

Quand tu travaille en client/serveur, le mieux est de se mettre d'accord sur une timezone précise à utiliser des deux cotés. Ensuite, pour tous tes appels à DateFormat, passer cette timezone pour être certains que la locale (Timezone.getDefault()) de la machine ne soit pas prise en compte.

Pour te donner un exemple, ici, j'avais une application en JSF, le serveur était sur GMT, les utilisateurs sur Europe/Brussel. Résultat, perte de 1 à 2 heure suivant la période de l'année. Comme je sauvais des "dates" sur la db oracle, 1h de décalage, par rapport à minuit, çà change carrément de jour, comme oracle tronque les heure (pas besoin pour les "date", à chaque cycle de charger / modifier / sauver, je perdais un jour sur tous mes champs dates . La solution a été d'imposer partout une timezone explicite (Europe/Brussel), y compris sur le connecteur db

[adiGuba]

Salut,

C'est pas comme çà que çà marche, la date, en elle même, n'a pas de timezone. Elle n'est donc pas convertie lors du passage sur RMI. C'est uniquement lors de sa convertion de et vers des strings que la timezone est utilisée.

+1

Une date est toujours stocké à l'heure GMT. Ce n'est que lors de l'affichage ou de la création d'une Date que l'on utilise un TimeZone.

Ainsi ce code ne génèrera pas la même date : cela dépend du timezone par défaut :

Code :

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

new GregorianCalendar(1978, Calendar.JANUARY, 1)

Perso je ne vois donc pas vraiment de problème... mais la gestion des TimeZone est assez complexe

a++

[gronono]

Je viens de relire la discution.
J'ai fait une petite erreur. Les deux timezones ne sont pas identiques. Elles correspodent toutes deux à GMT+11 mais Pacific/Noumea (ie heure de Nouvelle-Calédonie) et Pacifisc/Guadalcanal (ie heure des îles Solomon n'ont pas le même historique.
En effet, Pacific/Noumea a bien eu une heure d'été en 1978.

Le problème est que Windows ne distingue pas les deux fuseaux. Sous linux, on sélectionne le fuseau à partir de la ville (ici Noumea). Mais sous Windows ont sélectionne GMT+11.

Donc sous Windows, on se retrouve avec le fuseau Pacific/Guadalcanal qui n'a pas d'heure d'été en 1978.

La solution consiste bien à forcer le fuseau.

Par contre je croyais que spécifier la locale en fr_NC forçait aussi le fuseau horaire. Mais c'est faux.

Par contre je ne sais toujours pas comment jvm peut savoir qu'en 1978, il faut utiliser l'heure d'été.

A+
Gronono

Edit : Le convertit par RMI était un peu fort. Je sais bien que le RMI n'y est pour rien. L'important était d'avoir des jvms distinctes pour le client et le serveur. Le test devait alors lieux entre un client windows et un serveur linux comme en production.