Comment 23 for bug 49068

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