[JBS] (JDK-8026842) Remove Time-Zone IDs HST/EST/MST

[Stephen Colebourne]

I've emailed the ThreeTen lists to ensure everyone knows about this.

To balance the points below, it should be noted that
(1) they've been deprecated in TimeZone for a long time
(2) their meaning has changed over time
(3) they lead to user bugs, where someone finds EST exists and thus
assumes that EDT/CST/CDT/PST/PDT exist as well (which they do not)

The complete set of short IDs in ZoneId right now is:
[HST, GMT, UCT, PRC, MET, CET, WET, EET, UTC, EST, MST, ROK]

UTC/UCT/GMT are fine.

WET/CET/EET are fine because they are trans-national IDs in Europe,
and represent something that cannot be represented in any other way.

MET is an equivalent/translation of CET. This is undesirable, but less
bad than HST/MST/EST. However, ECT (another translation) has been
removed.

PRC/ROK are equivalent of Asia/Shanghai and Asia/Seoul. Undesirable,
but less bad than HST/MST/EST.

The fully aggressive approach would remove PRC/ROK/MET as they add no
value. And yes removing PRC/ROK/MET would be my preference. However
since they are less bad than HST/MST/EST and its late I can live with
them staying if necessary. (Removing them would require adding them to
SHORT_IDS)

The complete list in TimeZone is:
[HST, ACT, PRT, IST, ECT, CNT, PNT, EET, EAT, AET, NST, GMT, ART, BST,
PRC, AGT, UTC, CAT, MIT, ROK, MST, CST, NET, UCT, PST, MET, BET, CET,
VST, IET, AST, WET, JST, EST, PLT, SST, CTT]

The set in SHORT_IDS handles these TimeZone IDs.


On the webrev, I would have left the tazdb data file alone and just
patched it in ZoneId when reading the file. However, your approach
will result in a slightly smaller data file, so its fine by me.

Stephen


On 18 October 2013 18:14, Xueming Shen <xueming.shen at oracle.com> wrote:
> 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.shen at 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
>
>