My friend seva is an admin of some unix boxes (including linux) at a firm that does some stockish stuff. Appearently, some of their applications are based on java. He was running into a weird situation where the box was in EDT (where it lived) and but java kept thinking it was CDT (where the box was originally.) Well, it was reporting “America/Chicago” technically.

/etc/localtime contains the proper timezone, and the system is working like its in EDT. It’s just java that’s acting funky. He brought this up on IRC, and we both started digging into it.

I started looking into how java finds the default information via java.util.TimeZone. It tries to use System.getProperty("user.timezone"), if that fails then it then calls a native method passing along user.country and user.home. So, that dead-ended me.

Seva found the only place that “America/Chicago” was being used was in /etc/sysconfig/clock which only appeared to be used in startup and shutdown routines when calling hwclock. He changed it so the correct value was being put in ZONE, and Java acted how it should.

I ran strings on $JAVA_HOME/jre/lib/i386/libjava.so and found references to /etc/sysconfig/clock as well as ZONE=". So, it appears, at least on Linux systems, Java will read /etc/sysconfig/clock and if that’s succesful, not even bother checking with /etc/localtime.

This, I feel, is totally incorrect behaviour and against what one would expect from a UNIX system. This should probably be changed, but most likely won’t be. I figured I’d drop a note about it here in the blog to help others in the future as we couldn’t easily find the defined behaviour on the web.

Seva complained that he would have found this much faster using strace, but on the RHEL3 box he was using, strace segfaulted when he run against java. Works fine on my FC1 box, and I could recreate it and see it. So I guess this is also Linux dumbness of the day.