Hi Stephen,
As I said before that while I agree that these three short ids are kinda
of confusing
and understand the desire of removing them but I'm also concerned that
the fact
(1) these ids been in the "available timezone ids" from the j.u.TZ for a
long time
(2) these ids are defined in the official tzdb database (together with
couple others)
(3) and arguably the EST and MST are "popular" ids used in the real world
so it might cause usability complain if they are missing from the
ZoneId's available
list and the app will have to use the ZoneId.of(name, SHORT_IDS) to gain
the access.
That said, if this is the strong opinion from the EG :-) here the webrev
for it
http://cr.openjdk.java.net/~sherman/8026842/webrev/
Thanks!
-Sherman
On 10/17/13 3:16 PM, Stephen Colebourne wrote:
On 17 October 2013 22:14, Xueming Shen <xueming.s...@oracle.com> wrote:
On 10/17/2013 02:01 PM, Stephen Colebourne wrote:
I'm happy with the contents of this webrev.
As pointed out previously, it doesn't address the specific issue in
8025971
I will file a separate issue to address the issue. I would assume you are
recommending
to complete remove these three short ids from jvm?
I'm recommending removing these three IDs from ZoneId. For example:
ZoneId.of("HST") should throw an exception
ZoneId.of("HST", SHORT_IDS) should succeed and return the matching
ZoneOffset UTC-10:00
TimeZone.of("HST") should succeed and return an offset-based TimeZone
with the HST ID
TimeZone.of("HST").toZoneId() should succeed and return the matching
ZoneOffset UTC-10:00
TimeZone.of("HST").toZoneId() with old mappings flag equal to true
should succeed and return the Honolulu zone.
Thus, myZoneId.getId() will never return "HST".
Stephen
