Java and timezone issues!

NoOp glgxg at
Mon Apr 20 20:24:28 UTC 2009

On 04/20/2009 11:29 AM, John L Fjellstad wrote:
> Knute Johnson <knute2009 at> writes:
>> Will you try my applet at
>> and see if it gives you the correct time?  Do you have 
>> /etc/sysconfig/clock or any of the other places that Java looks for 
>> timezone info?  Which version of Java are you running?
> $ java -version
> java version "1.6.0_13"
> Java(TM) SE Runtime Environment (build 1.6.0_13-b03)
> Java HotSpot(TM) Server VM (build 11.3-b02, mixed mode)
> Gives correct time here (CEST)

On _hardy_ I get the correct time using:

1st machine: $ java -version
java version "1.6.0_11"
Java(TM) SE Runtime Environment (build 1.6.0_11-b03)
Java HotSpot(TM) Client VM (build 11.0-b16, mixed mode, sharing)

2nd machine: 1.6.0_07.

I have also tested with _10.

On _intrepid_ I do not get the correct time, it is one hour behind. I
tested on two machines, both using 1.6.0_10.

I have not modified any of my tzdata settings & even used 'sudo
dpkg-reconfigure tzdata' to ensure.  None of my systems (hardy &
intrepid) have /etc/localtime
symlinked. Now, usr/share/zoneinfo/localtime is a symlink *back* to
/etc/localtime. Nor should they (normally) be according to this:

Martin Pitt's suggested workaround for a tzdata race condition:
    # Update the timezone
    echo $AREA/$ZONE > /etc/timezone
    cp -f /usr/share/zoneinfo/$AREA/$ZONE /etc/localtime.dpkg-new && \
	mv -f /etc/localtime.dpkg-new /etc/localtime

@Knute & David: recommend that you file a new bug under tzdata & use
Knute's clock applet as the test case. Mention that I cannot reproduce
under hardy, but can under intrepid - I'll be happy to add to the bug
report after it's filed.

More information about the ubuntu-users mailing list