<i18n dev> Using system tzdata

[Masayoshi Okutsu]

Sorry again for taking time. Finally, I talked to some sustaining team 
members in Ireland to make a decision on the long-term tzdata 
maintenance issue. We've determined that Sun would need to continue to 
use the tzupdater tool as the main vehicle to deliver new tzdata files 
for Java runtime. Therefore, the proposed property needs to be supported 
for those who want to use another mechanism to update tzdata files.

I need to get approval on the proposed property support because it 
exposes an interface (even it's internal). To do that, I need to make a 
decision on the default value. I've been having some difficulty to think 
of default locations for other platforms, especially Windows. So I 
wondered if it's OK to make the property value undefined by default. 
Would that be acceptable for you?

Thanks,
Masayoshi

On 12/21/2007 11:59 AM, Masayoshi Okutsu wrote:
> 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
>>>
>>