[threeten-dev] Fwd: Re: j.u.Date/Calendrical/GregorianCalendar

[Xueming Shen]

Forwarded to threeten-develop at lists.sourceforge.net


-------- Original Message --------
Message-ID: 	<50BEE601.7080200 at oracle.com>
Date: 	Tue, 04 Dec 2012 22:13:21 -0800
From: 	Xueming Shen <xueming.shen at oracle.com>
User-Agent: 	Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) 
Gecko/20121026 Thunderbird/16.0.2
MIME-Version: 	1.0
To: 	Stephen Colebourne <scolebourne at joda.org>
CC: 	Roger Riggs <Roger.Riggs at oracle.com>, threeten-dev at openjdk.java.net
Subject: 	Re: j.u.Date/Calendrical/GregorianCalendar
References: 	<50BE312C.9030708 at oracle.com> 
<CACzrW9Cz0mwW=cPLsRxc61OnNqxvhqyZgNK3gaa6LXMKde_ZBQ at mail.gmail.com> 
<50BE532F.9040903 at oracle.com> 
<CACzrW9BRm1YV8zEgCELr3pmFAiT_okECLR1zgBxtWaoBqyS2qA at mail.gmail.com>
In-Reply-To: 
<CACzrW9BRm1YV8zEgCELr3pmFAiT_okECLR1zgBxtWaoBqyS2qA at mail.gmail.com>
Content-Type: 	text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 	7bit



Agree this should be discussed in public mailing list. My fault, I
thought I was asking
a simple/solved question:-)

My take on this is that we should provide a bridge between these two
systems, but not
integrate these two together (in which you try to provide convenient
conversion between
all those different date/time types, or even go a little further to make
it possible to access
all corresponding threeten fields from a GregorianCalendar).

Date <-> Instant appears to be a must, in which it provides the
connection/conversion
at the bottom between two different systems, so we don't need Date <->
ODT for
example.

How to support the Date <-> Instant?

I believe we only need ONE straightforward/direct conversion, don't need
to provide
multiple convenient vehicles here, developer should just use this entry
point to convert
between these two types. As you suggested, use nio.file as an example, a
simple pair
of File.toPath() and Path.toFile() should be good enough.

Date.toInstant() and "util.Date must support the same fields as Instant -
INSTANT_SECONDS and the three fractional seconds fields" are obviously
redundant.
With this, now you can do

Date date = ...;
Instant instant = date.toInstant();

or

Instant instant = Instant.from(date);

If we don't need two, which one is better? DateTimeAccessor appears to be
convenient, with this, you can also do OffsetDateTime.from(date), and
any "extended"
date/time that knows INSTANT_SECONDS+fractional sec fields can work with
u.Date
as well. But it also brings us the biggest problem, all of the sudden,
j.u.Date can fly
freely inside the new JSR310 system. Conveniently, our datetime
formatter also magically
work with j.u.Date. Is this something you want to see? It appears to be
an integration
of two systems, not a bridge. Sure, it provides convenience, but it also
has the
consequence, you now have a mutable DateTimeAccessor running around your
JSR310
code.

So personally I think a simple Date.toInstant() is the best choice, it
provide a "single"
entry point for all those "old" date/time. The code that uses JSR310
date/time should
just work with new date/time, old date/time need to be converted into
new types to
get in.

A Instant.toDate() will be a little confusing, I would suggest just do
Date.fromInstant().

So my vote will be Date.to/fromInstant().

In theory, it's doable to bridge the conversion of GregorianCalendar and
ZDT by

      GregorianCalendar <-> Date <-> Instant <-> ZDT,

but obviously the "zone" is missing, it's probably not desirable to use
"default". So, it
appears GregorianCalendar <-> ZDT is another candidate. For same reason
I mentioned
above, I don't think you want to "integrate" GregorianCalendar into the
new system, stop
it by forcing it to be the immutable ZDT before any new code can touch
it. Otherwise,
the worse thing is that, not like j.u.Date, those "setting" methods of
GregorianCalendar
are not deprecated.

Should we do the Calendar <-> Instant, personally I don't think we want
to do it. There
is a direct conversion between Date <-> Calendar via
setTime/getTimeInMillis, so
I don't think developer will whine too much on missing a "convenient"
direct conversion
between these two. But I will probably not be too strong to against the
idea of having
to/fromInstant() pair on it, especially the toInstant(), given
Calendar/GregrianCalendar
is one of the most frequently used date/time types in current system.

-Sherman


On 12/4/12 2:56 PM, Stephen Colebourne wrote:
> This should really be public...
>
> On 4 December 2012 19:46, Roger Riggs <Roger.Riggs at oracle.com> wrote:
>> I'd like to see the simplest practical coupling.
>>
>> I'd rather developers get used to use the 310 types.from() methods to convert.
> The closest JDK parallel is the addition of the new file system API.
> The old one - File - has a method toPath(). The same principle applies
> here. Not having toInstant() is just being mean to developers.
>
>> In my opinion, the classes should implement DateTimeAccessor. They
>> should also have some additional methods:
>> Date.toInstant()
>> Date.from(DateTimeAccessor)
>> Calendar.toInstant()
>> Calendar.from(DateTimeAccessor)
>> GregorianCalendar.toZonedDateTime()
>> GregorianCalendar.from(DateTimeAccessor)
>>
>> What fields are required to say it supports DateTimeAccessor?
> util.Date must support the same fields as Instant - INSTANT_SECONDS
> and the three fractional seconds fields.
> Calendar is the same.
> GregorianCalendar should support the full range of additional fields.
>
> Supporting only ZoneId, which would be enough for conversion to ZDT,
> is possible with a future JDK adding the remaining fields. However,
> this would be a violation of the spirit of DateTimeAccessor though,
> and I suspect users would complain.
>
>> GregorianCalendar might benefit from toLocalDate() and toLocalTime().
>>
>> Special handling will be needed for the sql subtypes of util.Date -
>> sql.Date, sql.Time and sql.Timestamp.
>>
>> If JDBC is going to encourage using the new 310 types then
>> these do not need to be enhanced.
> If util.Date implements DateTimeAccessor then these three classes
> *have* to be dealt with too. They will inherit the implementation from
> util.Date, which is entirely wrong for the three subclasses.
>
> sql.Date should act like a LocalDate, sql.Time like a LocalTime
> (confirm with Douglas). Neither should return INSTANT_SECONDS.
>
>
>> xml.XMLGregorianCalendar should implement DateTimeAccessor
>>
>> xml.Duration should implement PlusAdjuster and MinusAdjuster
>>
>> I'd leave these out, it encourages mixing APIs; not just interoperation
>>
>> TimeUnit should implement PeriodUnit
>> (DAYS in TimeUnit will be different to DAYS in ChronoUnit as it is
>> exactly 24 hours)
>>
>> Keep the cross coupling of the APIs to what is really needed,
>> mixing the APIs will make developers dizzy.
>>
>> FileTime should implement DateTimeAccessor
>> (amusingly, the toString method follows the broken XML Schema text
>> which wrongly has the year before 0001 as -0001).
>>
>> We'll need to consult with the other API owners about the couplings.
> Ultimately these APIs are outside 310/my control. It is my opinion
> that the above should be implemented, and if they are not developers
> will have a harder job than they should. In addition, some conversions
> (like FileTime) may be tricky (due to the missing year zero) so these
> implementations will actually reduce bugs.
>
> I do know that the developers of FileTime considered using 310 but the
> schedules obviously didn't match up.
>
> Stephen