Comment 25 for bug 49068

Revision history for this message
Christian Assig (chrassig) 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.