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.s...@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.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 > >
