<i18n dev> Using system tzdata

[Masayoshi Okutsu]

A problem is that the OS tzdata doesn't contain enough information for 
supporting the java.util.Calendar API. Otherwise, it would be 
unnecessary to provide JDK's own tzdata files.

Masayoshi

Martin Buchholz wrote:
> I don't know anything about how the Olson database is implemented
> or accessed on any particular OS..... I'm just brainstorming here.
>
> Say someone creates their own timezone definition MYTZ and adds it
> to the OS database.  If Java fails to lookup any such timezone,
> it seems reasonable to consult the OS.
> Similarly if the OS has a more up-to-date database with a newly
> defined timezone.  (But that's rare)
>
> If the JDK and the OS agree on the current timezone definition,
> all is wonderful.  If they differ, perhaps it is worth figuring
> out which is newer, even if that is difficult.  Perhaps it's worth
> snooping around in /usr/share/lib/zoneinfo.
>
> Martin
>
> Masayoshi Okutsu wrote:
>   
>> Tzdata for Java does have the Olson version information (eg,
>> tzdata2007k), but I don't think the OS tzdata has it. But I don't know
>> what Java should do if it was possible to check OS tzdata version. Can
>> you elaborate your suggestion a bit more?
>>
>> Thanks,
>> Masayoshi
>>
>> On 1/30/2008 8:51 AM, Martin Buchholz wrote:
>>     
>>> Dalibor Topic wrote:
>>>  
>>>       
>>>> Masayoshi Okutsu wrote:
>>>> From the POV of operating system distributors that already need to
>>>> support tzdata for other applications, and therefore need to keep it
>>>> current anyway for their customers, I think it's preferable to rely on
>>>> system facilities where such facilities exist, than to have to push a
>>>> separate patch for the Java runtime.
>>>>     
>>>>         
>>> Perhaps the best behavior is to check whether the system database is
>>> at least as up to date as the Java database.  Could Java know
>>> about the "last" change to its own database, query the OS as to whether
>>> it "knows about" this specific change, and if so, defer to it?
>>>
>>> Martin
>>>
>>>  
>>>       
>>>> cheers,
>>>> dalibor topic
>>>>     
>>>>