[threeten-dev] Integration with other JDK classes

[Michael Nascimento]

Seems like a reasonable list of classes and modifications to them. +1.

Regards,
Michael

On Wed, Dec 5, 2012 at 12:46 PM, Stephen Colebourne
<scolebourne at joda.org> wrote:
> The question is to what degree should existing JDK date/time classes
> support integration with 310?
> Key open question to everyone is how much integration should be done?
>
> Here is my list and proposls:
> util.Date - implement DateTimeAccessor (INSTANT_SECONDS and fractional
> second fields)
> sql.Date - implement DateTimeAccessor (EPOCH_DAY and related)
> sql.Time - implement DateTimeAccessor (NANO_OF_DAY and related)
> sql.Timestamp - implement DateTimeAccessor (all ChronoField)
> Calendar - implement DateTimeAccessor (all ChronoField)
> GregorianCalendar - implement DateTimeAccessor (all ChronoField and zone)
> FileTime should implement DateTimeAccessor
> xml.XMLGregorianCalendar should implement DateTimeAccessor
> xml.Duration should implement PlusAdjuster and MinusAdjuster
> TimeUnit should implement PeriodUnit
>
> In addition, some common additional methods would be very helpful:
> Date.toInstant()
> util.Date.from(DateTimeAccessor)
> sql.Date.from(DateTimeAccessor)
> sql.Time.from(DateTimeAccessor)
> sql.Timestamp.from(DateTimeAccessor)
> Calendar.toInstant()
> Calendar.from(DateTimeAccessor)
> GregorianCalendar.toZonedDateTime()
> GregorianCalendar.from(DateTimeAccessor)
>
> GregorianCalendar might beneft from toLocalDate() and toLocalTime().
>
> The sql subtypes of util.Date are of course troublesome. The JDBC
> group need to advise on whether they consider them effectively
> deprecated or not.
>
> DAYS in TimeUnit will be different to DAYS in ChronoUnit as it is
> exactly 24 hours.
>
> I think that is all the JDK date/time classes. I could be wrong...
>
> Stephen
> (This was a private discussion being made public)