Time und Zeitzonen

[thorsten_w]

Hallo @ all,

ja mich gibt es noch .

Ich komme auch gleich mit einer Frage. Ich habe ein Problem mit der Eingabe von Zeiten in einer Maske vom Web aus.

Im WebQuerySave Agenten steht dies:

Code

	DateTime start = (DateTime)context.getItemValue("time_start").elementAt(0);
	DateTime end = (DateTime)context.getItemValue("time_end").elementAt(0);
				
	System.out.println (start);
	System.out.println (end);

	System.out.println ("GMT: " + start.getGMTTime());
	System.out.println ("GMT: " + end.getGMTTime());

	System.out.println ("Local: " + start.getLocalTime());
	System.out.println ("Local: " + end.getLocalTime());
				
	Date dstart = start.toJavaDate();
	Date dend = end.toJavaDate();

	System.out.println (dstart);
	System.out.println (dend);

auf der Serverkonsole wird nun das ausgegeben:

Code

24.02.2006 08:44:07   HTTP JVM: 13:00:00
24.02.2006 08:44:07   HTTP JVM: 17:00:00
24.02.2006 08:44:07   HTTP JVM: GMT: 13:00:00
24.02.2006 08:44:07   HTTP JVM: GMT: 17:00:00
24.02.2006 08:44:07   HTTP JVM: Local: 13:00:00
24.02.2006 08:44:07   HTTP JVM: Local: 17:00:00
24.02.2006 08:44:07   HTTP JVM: Fri Feb 24 14:00:00 CET 2006
24.02.2006 08:44:07   HTTP JVM: Fri Feb 24 18:00:00 CET 2006

Im Serverdokument ist dies hier zu lesen: This server is using the OS's time zone and daylight saving time rules.

und das Betriebssystem ist entsprechend eingestellt und reagiert auf die Sommerzeit.


Hat irgendeiner eine Idee woran das liegt?

Gruss Thorsten.

[flaite]

Hat irgendeiner eine Idee woran das liegt?

Leider nein. Aber ich hab dringend Bedarf mir diesen Calendar-Wahnsinn mal ein bischen anzuschauen.
In reinen Javaumgebungen bin ich ein Anhänger von dem hier:
http://joda-time.sourceforge.net/
Ansonsten habe ich selbst in diesen Bereich einige Verwirrung (gerade auch in java.util.Calendar und java.util.Date).  Die entsprechenden Klassen funktionieren as designed, sind aber massiv unpraktisch in vielerlei Hinsicht. Deshalb Joda Time. 

Was bei deinem Beispiel "falsch ist", ist imho der Wert von start.getLocalTime() -> Das sollte nicht gleich wie GMT sein. WIR LEBEN NICHT IN DER GMT ZEITZONE SONDERN IN DER CET.

Pass v.a. höllisch bei java.x.Date auf, dass du nicht aus Versehen (import-statements) java.sql.Date verwendest.

gruß Axel

[thorsten_w]

Was bei deinem Beispiel "falsch ist", ist imho der Wert von start.getLocalTime() -> Das sollte nicht gleich wie GMT sein. WIR LEBEN NICHT IN DER GMT ZEITZONE SONDERN IN DER CET.

Das ist genau mein Problem  Schaut so aus, als würde der Server der Meinung sein er stehe in Greenwitch ^^

Pass v.a. höllisch bei java.x.Date auf, dass du nicht aus Versehen (import-statements) java.sql.Date verwendest.

Mach ich

[flaite]

In java.util.Calendar (und subklassen), java.util.Date und java.sql.Timestamp gibt es definitiv auch gotchas.
Z.B. scheint

Code

Calendar cal = Calendar.getInstance(); 

zu anderen Ergebnissen zu kommen als

Code

GregorianCalendar cal = (GregorianCalendar) Calendar.getInstance(); 

Das kann die Ursache für ein Problem sein, für das ich vor 2 Wochen Lotus Implementierung von Webservices verantwortlicht gemacht habe. Werd das dann aber noch komplett berichten.
Kann sein, dass meine Sicht für die Verantwortlichen der Java Spezifikation einfach zu eurozentrisch ist. Schliesslich gibts noch andere Kalender als den Gregorianischen.
Die sich daraus ergebenen Komplexitäten können aber echt verwirrend sein.
Man kann mal ein

Code

System.out.println(Calendar.getInstance()); 

machen und staunen, was allein alles in der toString() Implementierung der entsprechenden Implementierungsklasse alles für mitteilenswert erachtet wird.