<i18n dev> Using system tzdata
Masayoshi.Okutsu at Sun.COM
Fri Feb 1 05:11:30 PST 2008
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.
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.
> 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?
>> 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?
>>>> dalibor topic
More information about the i18n-dev