-Duser.timezone

[Paul Sturrock]

I'm investigating reasons why a JVM is not paying attention to this parameter. As I understand it, this parameter is used to define the default time zone the JVM uses. You need to supply it a value the JVM will recognize, i.e. something like Europe/London. This value is peculiar to Java, so the JVM maps it to a time zone value in in the OS the JVM runs on via the tzmappings file (in jre/lib) and the data files in the jre/lib/zi directory. The JVM can then defer to the OS to tell it the date format etc. If the value of the user.timezone property is not mapped, the JVM defaults to GMT.

So, possible reasons why the parameter would be ignored:

the user.timezone value is a garbage value

the user.timezone value is what would normally be a valid value, but there is no mapping for it in the JVM (for whatever reason)

the OS can't supply a time zone for this mapping

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 ]

[Paul Clapham]

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.)

However I seem to recall that

-Duser.timezone=America/Arizona

didn't work and I had to do

-Duser.timezone='America/Arizona'

instead. This was on an IBM iSeries CL program but it may apply to your system as well.

[Paul Sturrock]

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.

[Paul Clapham]

It's true that if you don't specify a timezone, the JVM will ask the OS for some information and decide upon a timezone from that. But if you do specify a timezone, you're bypassing the tzmappings file and going directly to the /jre/lib/zi directory. At least that's what I would have thought.

[Ole Hornischer]

Hi everyone!
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?

Regards,
Ole

[Rob Spoor]

Please http://faq.javaranch.com/java/DontWakeTheZombies

Are you sure the problem is Java related? Is it not your operating system that is causing these timing issues?

[Ole Hornischer]

Sorry for resurrecting a zombie.

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.

--Ole