Masayoshi Okutsu wrote:
Therefore, the proposed property needs to be supported
for those who want to use another mechanism to update tzdata files.
I don't believe that my proposed change in any way conflicts with the
status quo. If the property is defined, tzdata is read from the value of
the property. If the directory is not valid (or ZoneInfoMapping doesn't
exist) or if the property is otherwise undefined or invalid, it is
simply ignored, and the JDK-supplied tzdata is used instead. [Although I
admit, allowing this property to change makes me nervous. I would rather
it ALWAYS use the system data or NEVER use it -- rather like how OpenJDK
behaves today.]
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.
Default, platform-specific values, no?
I've been having some difficulty to think
of default locations for other platforms, especially Windows.
I don't think Microsoft would ever release tzdata for use by Sun's JRE,
but I could just be pessimistic. O:-) The only hosts that this really
affects are Solaris and Linux.
So I wondered if it's OK to make the property value undefined by
default. Would that be acceptable for you?
While our (Red Hat) hands are tied, of course, I would not agree with
the decision to turn this off by default, effectively ignoring the
problem that the patch is attempting to address.
Is there really no solution to this problem?
Keith
