So, possible reasons why the parameter would be ignored:
Does anyone know any other reason why this value could be ignored? Has anyone come across a particular JVM version causing problems (mine is Hotspot 142_10)? Or am I completely misunderstanding how this works?
[ September 04, 2006: Message edited by: Paul Sturrock ]
However I seem to recall that
didn't work and I had to do
instead. This was on an IBM iSeries CL program but it may apply to your system as well.
My impression was that Java got all the timezone info from those jre/lib and jre/lib/zi files, and that the OS had no input into the process at all. (Platform independence and all that.)
Yeah, I'd always assumed it was platform independent till I looked at the contents of the tzmappings file (and read this atricle). Quoting the parameter doesn't help though, unfortunately it is still a mystery.
I just encountered an odd phenomenon yesterday and am wondering now, whether it is a timezone related effect.
Our clients server was set to timezone Europe/Berlin and was always off by about 90-100 sec (can't recall exactly how much, location is Krefeld in Germany). Once we switched the server to run on timezone Europe/Paris the times were correct (to a few seconds). I always thought Java also handles timezones by the hours and not by the longitude. So are those seconds difference due to the different timezones (although Paris and Berlin should be on the same time) or is the effect caused by sth else and just happens to be fixed with the timezone for Paris?
Are you sure the problem is Java related? Is it not your operating system that is causing these timing issues?
I pretty much was just wondering about how Java does calculate the time.
The server is on a completely wrong timezone, so it is technically a problem for the admin, but I was surprised about the unexpected difference in "Europe/Berlin" and "Europe/Paris" on our JBoss server.
I did google a bit more, and did read about the tzmapping file and how different JVMs map the system tz to Java tz.
And HPUX JVM is significantly different to Windows JVM as I could see.
Anyhow, in the end it does not matter, as I mentioned above, it was plain curiosity.