Moin..

Die Erklärung ist heute so einfach wie vor 2 Jahren (ich glaube ich hatte damals
recht einsilbig "UTC" als schuldigen vermutet) ..

Aus "meiner" Perspektive ist Windows schuld.

Wieso ? .. Naja, eigentlich ganz einfach. Ich nutze Linux.

Ein Java-Programm unter Linux greift auf die Systemuhr zu. Da Linux dieselbe Art
und Weise wie Java nutzt, die Zeit zu speichern, UND in meinem Bios ebenfalls darauf
Rücksicht genommen wird, stimmen BIOS-, Linux- und Java-Systemzeit überein.
Java nimmt BIOS - Zeitzone = richtige Zeit.
(Linux speichert die Uhrzeit im BIOS in UTC. Daher zeigt Java dieselbe Zeit wie das
System an, weil beide "BIOS/Linux + Zeitzone" machen. )

Unter Windows wirds nun "kriminell" .. BIOS und Windows-Zeit stimmen überein,
und zwar mit der unter Windows eingestellten Zeitzone. Java nutzt primär UTC, greift
aber EBENFALLS auf die Zeitzoneneinstellung zurück. Und hier passiert dann Murks.

Denn wenn man z.B. "GMT + 2" einstellt.. dann ist die Systemzeit als Beispiel 16 Uhr.
GMT ist dann 14 Uhr. Im Bios steht 16 Uhr. Java nutzt Bios + Zeitzone -> 14 Uhr.

Stell im Bios die Zeit 2 Stunden später, dann geht natürlich auch deine Windows-Uhr
automagisch falsch. Stell die Windows-Zeitzone auf GMT/UTC, dann geht die Uhr wieder
richtig - und auch Java..

Was Crusader angeht: Naja, Zeitzone auf GMT+/-0 ist glaub ich ausser für eine
automatische Sommer/Winterzeit-Umstellung für Windows unwichtig, oder ? Aber
wenn man "intelligente" Programme hat, die die Zeitzone abfragen, werden dann
natürlich die für DE untypische Zeitzone zeigen.

Gruss,
Tim

PS: Das ist ein Windows-Bug! Eigentlich ein Logik-Bug, den der passende Windows-
Code seit... anbeginn der Windows-Zeit.. aufweist.

*EDIT* Zum "Windows-Beispiel": Warum ist BIOS + Zeitzone = - 2 Stunden? Na
weil Windows nunmal UTC = System -2 Stunden zurückgibt..