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

[Masayoshi Okutsu]

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.
>
> TimeZone.getTimeZone(ZoneId) has Javadoc that says {@code zoneid}
> rather than  {@code ZoneId}

Because it refers to the parameter name, not its data type.

> If you're insisting on the wrong ISO week definition override, then
> you should add "Note: there is no guarantee that toZonedDateTime() and
> from(ZonedDateTime) will round-trip." (based on the wording in
> Locale.forLanguageTag). ZDT is ISO in terms of year/month/day, but the
> week definition is kept separate.

GregorianCalendar can't separate the week definition. I think it's safer 
to be ISO compatible as defined by ZDT.

  * A date-time with a time-zone in the ISO-8601 calendar system,
  * such as {@code 2007-12-03T10:15:30+01:00 Europe/Paris}.

A GregorianCalendar produced from a ZDT should be compatible with the 
ISO 8601 calendar system (as much as possible). At least that is what 
I'd expect with the conversion.

Is the round-trip thing affected by the week definition? The Gregorian 
change value does, though.

Thanks,
Masayoshi

>
> Stephen
>
>
> On 5 February 2013 05:28, Xueming Shen <xueming.shen at oracle.com> wrote:
>> Stephen,
>>
>> It appears JDBC/SQL exports are fine with the "default zone" and don't want
>> UTC
>> versoin. So here is the proposed change for the j.util and j.sql date/time
>> classes.
>> The sql valueOf/toLocalDate/Time pair behave just like the
>> valueOf(String)/toString()
>> pair now.
>>
>> http://cr.openjdk.java.net/~sherman/jdk8_threeten/utilsql
>>
>> It is pointed out that the first sentence in ZDT API is
>> " A date-time with a time-zone in the ISO-8601 calendar system..." so the
>> iso 8601
>> week def setting stays in GC.from(ZDT), with the cost of roundtrip
>> conversion.
>>
>> -Sherman