Christian Assig wrote: > I have had a look at the Java source code. It took me about 30 minutes to > find the right file and analyse its behaviour. > The time zone detection for Linux is implemented in > j2se/src/solaris/native/java/util/TimeZone_md.c > > Java looks at the environment variable TZ first. > If it is not set, it reads /etc/sysconfig/clock. > If it does not find the file or a value for TZ in the file, it continues by > examining /etc/localtime. > If /etc/localtime is a symbolic link, the timezone is derived from the > destination of the link. > If /etc/localtime is a regular file, Java reads all the files in > /usr/share/zoneinfo and tries to find a file that is identical to > /etc/localtime. If a file is found, the time zone is derived from the path of > the file. > > I have found out that in my case, Europe/Amsterdam in > /usr/share/zoneinfo is identical to /etc/localtime, and in addition > there is a symbolic link called localtime pointing to /etc/localtime in > /usr/share/zoneinfo. After deleting the symbolic link > /usr/share/zoneinfo/localtime, Java detects the time zone correctly on > all systems. So I guess whether or not this bug appears depends on the > order in which Java cycles through the files in /usr/share/zoneinfo. If > it finds the symbolic link to /etc/localtime first, the detection fails > because the time zone cannot be derived from the path > /usr/share/zoneinfo/localtime. If it finds the regular time zone file > first, the detection succeeds. > > Possible ways to solve this bug that I could imagine would be to remove > /usr/share/zoneinfo/localtime (but it is probably needed by other > applications/libraries), to get the files in /usr/share/zoneinfo in the > correct order (bad) or implement a check in > j2se/src/solaris/native/java/util/TimeZone_md.c if the file > /usr/share/zoneinfo/localtime is a regular file and to skip all symbolic > links. >
Given the above information, I see three other possible solutions: 1. Add a check in TimeZone_md.c to have the second or third check be an attempt to read /etc/timezone (I don't like this because I'd rather not have Ubuntu specific modifications to the Java source if possible) 2. Modify whichever package(s)/program(s) currently copies the timezone file to /etc/localtime to create a symbolic link instead (I see no reason why this should be a problem; I've encountered no problems as a result of replacing the file with a symbolic link manually) 3. Modify the same package(s)/program(s) to create /etc/sysconfig/clock (I don't like this as well as 2 simply because I hate to see another directory added to /etc just to satisfy Sun Java when there is a better solution) After a little searching, at least one program that would need to be modified if solution 2 or 3 is adopted is /usr/sbin/tzconfig. Another thing that should be looked at is the installation scripts for the package tzdata, as it was an update to that package that recently removed the link I had created manually and forced me to recreate it. And I don't know whether all of the GUI administration tools that allow a user to change the timezone are wrappers around tzconfig or if they have another method for making the necessary changes. Allen Crider -- Java reports time zone incorrectly during CDT (US Daylight saving time) https://bugs.launchpad.net/bugs/49068 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
