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

[Masayoshi Okutsu]

I agree with Sherman. The new things should be imported into the old 
ones. But not the other way around.

The conversion between java.util.Calendar and 310 is very tricky.

java.util.Calendar to 310:

How about a similar approach to DateTimeFormatter.parse? Something like 
this:

   public <T> T to(class<T> type)

Performance may not be great, but it's clean.

310 to java.util.Calendar:

I prefer to introduce a Builder class in Calendar. I was planning to add 
Calendar.Builder support in JDK 8 for some different reasons. Also, 
TimeZone needs something like getTimeZone(ZoneID), and maybe another one 
from a ZoneOffset.

Thanks,
Masayoshi

On 12/6/2012 2:34 AM, Xueming Shen wrote:
> To implement DateTimeAccessor on Date/GregorianCalendar will not make
> the migration easier, it will actually prevent from migrating the old 
> code to
> new one. My experience indicates in most cases, developer will simply 
> pass
> around the old Date and GregorianC into the new date/time based code, if
> they can.
>
> Sure the spec of DateTimeAccessor does not say it should be implemented
> as mutable and yes, we have that "DateTimeBuilder" around. But I think
> one of the design goals of threeten is to have all date/time around 
> immutable,
> and this has been one of major reasons lots of suggestions have been
> rejected in the past year, why we want to open the door now for two
> well-known mutable date/time types from the "old" world. I don't see any
> reason why developer would be upset if they have to do date.toInstant()/
> cal.toZonedDateTime() before pass their old date/time into the new 
> system.
> Performance might be a concern for some apps, but this might just 
> motivate
> them to go up level a little to see if those Date and 
> GregorianCalendar should
> be Instant and ZDT at first place.
>
> -Sherman
>
> On 12/05/2012 07:15 AM, Stephen Colebourne wrote:
>> 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
>