<i18n dev> Using system tzdata
Keith Seitz
keiths at redhat.com
Wed Sep 19 11:28:33 PDT 2007
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
>
More information about the i18n-dev
mailing list