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.
>