<i18n dev> Using system tzdata

Keith Seitz keiths at redhat.com
Wed Sep 19 11:28:33 PDT 2007

[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