<i18n dev> Using system tzdata

[Masayoshi Okutsu]

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
>>
>