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.
Christian Assig wrote: solaris/ native/ java/util/ TimeZone_ md.c clock. zoneinfo. After deleting the symbolic link zoneinfo/ localtime, Java detects the time zone correctly on zoneinfo. If zoneinfo/ localtime. If it finds the regular time zone file zoneinfo/ localtime (but it is probably needed by other libraries) , to get the files in /usr/share/zoneinfo in the solaris/ native/ java/util/ TimeZone_ md.c if the file zoneinfo/ localtime is a regular file and to skip all symbolic
> 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/
>
> Java looks at the environment variable TZ first.
> If it is not set, it reads /etc/sysconfig/
> 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/
> /usr/share/
> 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/
> it finds the symbolic link to /etc/localtime first, the detection fails
> because the time zone cannot be derived from the path
> /usr/share/
> first, the detection succeeds.
>
> Possible ways to solve this bug that I could imagine would be to remove
> /usr/share/
> applications/
> correct order (bad) or implement a check in
> j2se/src/
> /usr/share/
> links.
>
Given the above information, I see three other possible solutions: s)/program( s) currently copies the timezone s)/program( s) to create /etc/sysconfig/ clock
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(
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(
(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