Comment 26 for bug 49068

I should have thought about the possibility of having
/usr/share/zoneinfo on a different partition. And I had doubts about
changing tzconfig being a good solution as it did not appear to be easy
to wrap. It would be much easier (at least for me) to reproduce the
needed functionality in whatever programming language an application was
written in than wrapping tzconfig.

I'm beginning to believe there is not going to be a nice long-term
solution to this problem unless Sun changes their code. As I see it
right now, we're coming down to just a few somewhat practical solutions,
all with drawbacks:

1. Modify the source for sun-java, either to add a new rule to look for
the file /etc/timezone if TZ is not set or to modify the way the rule
for /etc/localtime being a regular file works. If Sun were to
incorporate this change into their source, it would be the best
solution, but I don't like it otherwise. This probably comes down to
whether Ubuntu is handling time zones differently than other Linux
distributions (I haven't run any other distributions since installing
Breezy and don't remember how others did it before), and if so, whether
it is big enough for Sun to incorporate an Ubuntu specific fix.

2. Modify the installation script(s) for sun-java to provide one of the
things being looked for. That would probably come down to to either
creating the file /etc/sysconfig/clock or globally setting TZ. Since
I've never looked at /etc/sysconfig/clock (it doesn't exist on any of my
current systems), I don't know if that could be done in a manner that
wouldn't break the next time the user changed time zones, although I
doubt if many users do that very often. And I really haven't kept up
with whether there is a standard way for setting an environment variable
for all users. The way I would have done this in the past would have
been to add it to /etc/bash.bashrc or a similar file. This has the
disadvantage that it could possibly be lost the next time an update
replaced /etc/bash.bashrc.

3. Change the name of the java executable and create a wrapper script
that would set needed environment variables.

4. Modify applications that use this feature to work around it. For
example, the only application I use that has been affected by this bug
is FreeGuide. TZ could be set in the script /usr/bin/freeguide. I'm
not crazy about this solution, but it should work. OTOH, I don't know
what impact this might have on users that are using a different JVM.
However, the last time I tried (when I first discovered this bug on
Dapper), I was unable to get FreeGuide to run at all with any other
available JVM. I still can't get it to work with GCJ, but I haven't
tried installing any other JVMs.

I wish I had a better idea, but I can't think of anything else that
would work for everyone. For now, I can live with manually replacing
/etc/localtime with a link, although if it isn't solved, I'll probably
fall back on adding TZ to my .bashrc (workable on my personal system
that doesn't have any other users). Someone else will have to decide
whether it is a big enough problem for other users to implement a system
level fix.

Allen

Christian Assig wrote:
> @Mike
> You have to read Sun's statement you are quoting correctly. What it means: You do not have to update data about the time zones, such as when DST begins and ends, in your operating system. But Java detects the time zone you are in the way I have described it. That's what I could see in the sources, and that's also exactly the behaviour I could reproduce. Let me clarify again what Sun's statement means: When a country decides to change the way it handles DST (such as Western Australia did last year or the U.S. did this year), you get these changes about the DST attributes of your time zone into your Java virtual machine by updating Java, you do not have to update your operating system's time zone database. But this can only work if the Java VM knows in which time zone it is, which it does in the way I have described.
>
> @Allen
> Solution 2 may be a problem. The reason for /etc/localtime not being a link is that /usr/share/zoneinfo might be mounted from a different partition than /etc. So it may be possible at boot time that a program wants to read /etc/localtime before /usr/share/zoneinfo is mounted, which would fail if /etc/localtime is a symbolic link to /usr/share/zoneinfo.
>
> Regarding solutions 2 and 3: I already tried to rename
> /usr/sbin/tzconfig. KDE's time configuration tool is still able to
> change the time zone if /usr/sbin/tzconfig does not exists, so
> unfortunately it does not suffice just to change /usr/sbin/tzconfig, at
> least the KDE code would have to be changed, probably other packages as
> well.
>