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
