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

[Xueming Shen]

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.

Webrev has been updated.

http://cr.openjdk.java.net/~sherman/jdk8_threeten/utilsql

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

-Sherman

On 02/05/2013 07:53 AM, Stephen Colebourne wrote:
> On 5 February 2013 15:43, Masayoshi Okutsu<masayoshi.okutsu at oracle.com>  wrote:
>> On 2/5/2013 5:12 PM, Stephen Colebourne wrote:
>>> I still think TimeZone.toZoneId() should be added. Its going to be a
>>> pretty common conversion.
> Any thoughts on TimeZone.toZoneId() ?
>
>>> TimeZone.getTimeZone(ZoneId) has Javadoc that says {@code zoneid}
>>> rather than  {@code ZoneId}
>> Because it refers to the parameter name, not its data type.
> I was talking about the first line. I guess you could read that as a
> parameter, however I read it as a type.
>
> Stephen