Rebase JavaSE timezone data on native platform timezone infomation
by changing JavaSE to stop providing separate timezone data in parallel
to the local system timezone data (e.g. Solaris, Linux, MS/Windows,
Apple Mac-OS X). Such a change would:
. improve system management by providing a single point of maintenance for
    system timezone data (the native system), and
. lower cost of maintenance for JavaSoft product engineering by exiting the
    timezone provision business.

JavaSE had historically provided timezone data accurate at the point
of major releases, but not always accurate for maintenance or update
releases. Nor has JavaSE provided a mechanism for updating its
local TZ data store outside of a full release.

Historically there was a valid reason for JavaSE to provide it's own
TZ data. In the mid-1990's there was no accepted international standard
reference for global timezone information or format. System vendors
varied widely in how they implemented providing such data. Today,
there is still no authoritative international standard, but there
is an accepted convention of convenience: the open source Olsen data.
Most system vendors now follow the Olsen data, so the variability
across systems is much reduced.

The nature of timezone data world-wide is to change frequently.
The JavaSE approach of TZ data updates only with full releases has
provided an approximate solution at the time of release, and one
which erodes over time in deployment.

Allowing Java TZ data to be read directly from the local system
TZ data would allow JavaSE to track TZ data according to the
patch level of the local system -- or from a network service
the local system may utilize (e.g. Cisco enhancemented DHCP).