FULL PRODUCT VERSION :
java version "1.5.0_11"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_11-b03)
Java HotSpot(TM) Client VM (build 1.5.0_11-b03, mixed mode, sharing)
I believe the problem also occurs with 1.6.x.
ADDITIONAL OS VERSION INFORMATION :
Linux 2.6.18-4-686 #1 SMP Wed Feb 21 16:06:54 UTC 2007 i686 GNU/Linux
A DESCRIPTION OF THE PROBLEM :
Java detects the default system timezone is incorrectly under Debian Etch. I suspect the problem is not unique to Debian, as the root cause turned out to be that "/etc/localtime" is no longer a link, which is probably true for many Linux distrubutions (e.g. Ubuntu?).
The system is configured for "US/Pacific", however Java reports
"SystemV/PST8PDT". The latter timezone doesn't have the correct DST
settings in Java, so on top of that incorrect time is displayed. Perhaps the latter has to be fixed in a separately.
My diagnosis of the problem
I noticed that /etc/localtime is no longer a link in Etch. I changed
it back to a symbolic link to "/usr/share/zoneinfo/US/Pacific" and
Java started working correctly again.
My conclusion is that Sun JVM relies on the _path and name of the zone
file_ to determine the zoneID (which it then matches to its own
timezone database). However since in the file is no longer a
link, so they must be comparing it binary against all files under
"/usr/share/zoneinfo/SystemV/PST8PDT" is the same file binary as
""/usr/share/zoneinfo/US/Pacific", however it is found first !
To confirm this I restored "/etc/localtime" to its non-link state, and
deleted all directories under "/usr/share/zoneinfo" except "US". Voila
! Java worked again.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Steps to reproduce
- Configure the system timezone to US/Pacific (using tzconfig)
- In Java execute:
System.out.println( java.util.TimeZone.getDefault().getDisplayName() );
It will show "SystemV/PST8PDT"
- In Java execute "System.out.println( new java.util.Date() );". It
currently prints the incorrect time. It will probably start printing
correctly again soon, when we enter the old (pre-2007) DST period.
EXPECTED VERSUS ACTUAL BEHAVIOR :
This bug can be reproduced always.
---------- BEGIN SOURCE ----------
System.out.println( java.util.TimeZone.getDefault() )
---------- END SOURCE ----------
CUSTOMER SUBMITTED WORKAROUND :
These are the possible workarounds:
- Manually set the TZ environment variable. However in Debian-based distributions there is no way to set it globally, so this is not a practical solution.
- Use -Duser.timezone=US/Pacific in the java command line
- Change /etc/localtime to a symbolic link again