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

[Xueming Shen]

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