Comment 32 for bug 49068

People were mentioning writing the correct timezone information to /etc/sysconfig/clock aswell as an option, here is the format:
ZONE="America/New_York"
UTC=false
ARC=false

This doesn't seem like such a horrible idea. There may be even other (non-ubuntu pieces of software) that use the /etc/sysconfig/clock file that may benefit from this.

I use java pretty extensively on ubuntu servers/workstations, but I don't use the ubuntu packages, and I am affected by this issue aswell. I would have to recommend *against* changing the java source code to fix this issue... The average end-user probably doesn't care if they run an ubuntu modified version of java, or what SR of the 1.5.0 JVM they are running. But coming from a server environment, we are very closely tied to a version of java, right down to the SR and build number. Any JVM changes need to go through pretty extensive hardening; and as a result, we don't tie our JVM to a distro (also we have servers running different distros aswell). I also have over 10 different jvms installed on my workstation, and I flip between atleast 3 of those pretty regularly (i586, amd64, 1.6.0). It seems like the best solution is going to be one that works for JVMs out of the box, since I would guess most server environments are going to be seeing a non-ubuntu JVM on the system.

As far as I can tell, what timezone java thinks is correct appears to be random per machine (a quick check of 10 workstations appears to find a high level of variance depending on what ubuntu release they are running, if they were upgraded from older releases, and what architecture they are running).

I would strongly recommend a solution be found, and not wait for sun to save the day (which I've done in the past with not much luck). I don't have these problems on my redhat servers. Java is a very common server application, and it should really *work* on ubuntu servers, even if that means living with a non-ideal workaround (EG: writing out /etc/sysclock/config) for a few releases.