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. > -- 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 ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
