[threeten-dev] java.util and java.sql date-time-calendar

[Stephen Colebourne]

On 5 February 2013 18:15, Xueming Shen <xueming.shen at oracle.com> wrote:
>
> Added the toZoneId. The first thought was that it's a one line conversion,
> probably not worth it. But just realized that there is an "alias" issue,
> ZoenId
> does not take alias, except you put the alias table explicitly, and for the
> completeness.

You need to use the TimeZone.toZoneId() method in GregorianCalendar
for the same reason.

> Btw, Stephen, should we re-consider the spec/impl of "no alias" in the
> default ZoneId.of()? Given, we now have an extra layer on top of RegionId?
>
> It may not be convenient if developers have to explicitly attach the alias
> table
> to get the zoneId. Ideally I believe for most developers, they probably
> should
> not even be awared of the "idea" of alias. PST is a "normal" timezone name
> for west coast for people live here, JST is natural for Japanese people... I
> understand the possible confusion of the abbr, just wonder if we explicitly
> list them in the spec,  for those don't think PST should be us/los-angeles,
> the
> API does tell them it's NOT, so pick the real name. It does not work anyway
> for these group of people now. But if you want to force the people to do the
> "correct thing", with the cost of convenience...

The JDK TimeZone class says:
"For compatibility with JDK 1.1.x, some other three-letter time zone
IDs (such as "PST", "CTT", "AST") are also supported. However,
<strong>their use is deprecated</strong> because the same abbreviation
is often used for multiple time zones (for example, "CST" could be
U.S. "Central Standard Time" and "China Standard Time"), and the Java
platform can then only recognize one of them."

Continuing to support them in 310 seems like a continuing to support a
deprecation. Thats why the API doesn't support them without explicit
conversion.

It might be worth renaming OLD_IDS_POST_2005 to SHORT_IDS and
OLD_IDS_PRE_2005 to SHORT_IDS_PRE_2005 or SHORT_IDS_OLD as they are
perhaps clearer names.

Stephen