I apologize for the delay in responding. There have been some
discussions in Sun about long term directions on tzdata maintenance. We
might need to migrate to another mechanisms to update tzdata from the
current tzupdater tool due to other platform dependent issues. But we
haven't made a decision yet, and the discussion involves Sun's
sustaining team, which is taking time.
There are some further comments on the proposed changes, including ones
from Mark Reinhold.
* If a user used Sun's tzupdater tool to update tzdata in JDK/JRE,
the runtime would still pick up the older tzdata in
/usr/share/javazi, which would cause maintenance problems
(confusions). Do you plan to tell users that the tzupdater tool
should never be used to update tzdata?
* "user.zoneinfo.dir" is evaluated every time readZoneInfoFile()
gets called. This means that the runtime may pick up tzdata from
different locations if an application changed it during its
execution. Should the tzdata directory be determined only once
before reading tzdata first time?
* The property name should be named as sun.* so that it's clearly
understood as internal.
* The default value should not be set in HotSpot's os_linux.cpp
file, but rather in java_props_md.c.
* The proposal should include the default location for other platforms.
Thanks,
Masayoshi
On 9/20/2007 3:28 AM, Keith Seitz wrote:
Ping?
[I have not yet updated the RFE. I'm going to await further feedback.]
Keith Seitz wrote:
Masayoshi Okutsu wrote:
Sorry for taking time to respond.
Likewise!
I've filed an RFE for this request to make sure Sun's JRE supports
the same mechanism. Sun's Change Request ID (aka bug ID) is 6593486.
I'll add my comments/patch there, too, but I wanted to briefly let
you know what I've been up to with all of this.
* I think the "java." name space should be avoided for this
purpose.
"user.timezone.dir" should be OK.
Done.
* I'd also suggest that "/usr/share/zoneinfo/java" be changed to
something like "/usr/share/javazi" because Java runtime may
search
files under /usr/share/zoneinfo to detect the platform time zone
setting. It costs extra to skip all the files under
/usr/share/zoneinfo/java if the directory comes before other
directories in /usr/share/zoneinfo. Also I think
/usr/share/zoneinfo should contain the native Olson time zone
data
files only.
Done.
* I'm not sure if the current implementation is robust enough to be
able to reject all broken data files. It does check magic
numbers,
though. You may need extra tests with random directory paths. Or
you could add more checking to see if the directory is right,
such
as existence of the ZoneInfoMappings file.
I've added a little something so that the code will check for a
ZoneInfoMappings file before using the user.timezone.dir property.
Beyond this, there seems little reason to do any more extreme error
checking. The default is still to use the supplied, built-in tzdata.
If the user sets user.timezone.dir to something else, he should be
aware of what he is doing!
Thank you for your feedback,
Keith
