P3
This is the original issue described in JDK-8025971. That issue is now being used to trace another issue, to remove the "old_short_ids" mapping from the ZoneId class, raised during the discussion.
JSR-310 has two special maps to support backwards compatible handling of the old/broken IDs HST/EST/MST. However, they are still available via the normal ZoneId.of(String) method which is a mistake.
History. These three IDs were added in JDK 1.1 and were defined as DST bearing IDs equal to Pacific/Honolulu, America/New_York and America/Denver. In TZDB release 2005r the meanings were changed to be fixed offsets of -10:00, -05:00 and -07:00.
Thee IDs were intended to be filtered from the TZDB data in JSR-310. They are not currently filtered and need to be to avoid ongoing confusion. The filtering must occur in TzdbZoneRulesProvider or the underlying TZDB compiler.
Conversion from TimeZone to ZoneId is not affected as it uses a backwards compatibility shim as perJDK-8025971.
JSR-310 has two special maps to support backwards compatible handling of the old/broken IDs HST/EST/MST. However, they are still available via the normal ZoneId.of(String) method which is a mistake.
History. These three IDs were added in JDK 1.1 and were defined as DST bearing IDs equal to Pacific/Honolulu, America/New_York and America/Denver. In TZDB release 2005r the meanings were changed to be fixed offsets of -10:00, -05:00 and -07:00.
Thee IDs were intended to be filtered from the TZDB data in JSR-310. They are not currently filtered and need to be to avoid ongoing confusion. The filtering must occur in TzdbZoneRulesProvider or the underlying TZDB compiler.
Conversion from TimeZone to ZoneId is not affected as it uses a backwards compatibility shim as per