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
