<i18n dev> Using system tzdata
keiths at redhat.com
Mon Sep 10 13:10:45 PDT 2007
Masayoshi Okutsu wrote:
> Sorry for taking time to respond.
> 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.
> * 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.
> * 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,
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 1782 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/i18n-dev/attachments/20070910/08064cd1/attachment.bin
More information about the i18n-dev