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

[Stephen Colebourne]

On 5 December 2012 06:13, Xueming Shen <xueming.shen at oracle.com> wrote:
> 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.

DateTimeAccessor has always been known to be possibly mutable. Its an
interface, so nothing there can really be controlled. Having a
java.util.Date (or Calendar) work with the new immutable formatter
seems like a good thing - easy for developers to fix thread-unsafe
static formatters in their current code.

Integration is essentially what the system has been designed for.
Previous designs did it in different ways, but they all were planned
such that the old classes would implement the new interface, allowing
general use.

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

Clearly, this satisfies the basic problem, but its not what was
intended in the design (which was DateTimeAccessor).

There are actually four sensible options:

A) toInstant() and from(Instant), j.u.Date not implement DateTimeAccessor
B) toInstant() and from(DateTimeAccessor), j.u.Date not implement
DateTimeAccessor
C) from(DateTimeAccessor), j.u.Date implements DateTimeAccessor
D) toInstant() and from(DateTimeAccessor), j.u.Date implements DateTimeAccessor

I'd always intended (D), as it best matches the rest fo 310.

Note that (B), (C), (D) allow j.u.Date.from(zoneDateTime) or
from(offsetDateTime), which (A) does not, and these seem like useful
conversions.

OffsetDateTime.from(j.u.Date) will not work in any option, as there is
no offset.

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

Again, this works but isn't ideal. My aim was to provide an easy
migration, not a hard one.

Stephen