Bridge from JSR-310-types to Time4J - Githubissues

MenoData / Time4J

Advanced date, time and interval library for Java with sun/moon-astronomy and calendars like Chinese, Coptic, Ethiopian, French Republican, Hebrew, Hijri, Historic Christian, Indian National, Japanese, Julian, Korean, Minguo, Persian, Thai, Vietnamese

GNU Lesser General Public License v2.1

442 stars 65 forks source link

Bridge from JSR-310-types to Time4J #221

Closed MenoData closed 9 years ago

MenoData commented 9 years ago

In order to realize the reverse conversion, classes like PlainDate etc. should introduce new static methods with the signature public static PlainDate from(TemporalAccessor) or similar.

The class net.time4j.Duration might get new methods with the signatures public static Duration<U> from(TemporalAmount, Class<U>) and public static Duration<ClockUnit> from(java.time.Duration) and public static Duration<CalendarUnit> from(java.time.Period).

MenoData commented 9 years ago

After long investigation, the idea of static from(TemporalAccessor)-methods is finally rejected. Main reason is the philosophy of Time4J to preserve type-safety as much as possible. A type declared just as TemporalAccessor is not much better than using java.lang.Object. Code like Moment.from(LocalDate) or PlainTime.from(Instant) would compile and cause a runtime exception (due to missing timezone). Such from(...)-methods would also be in competition with the type-safe conversion class TemporalType and are mainly motivated by parsing purposes (within the scope of JSR-310). The readability of method references like PlainDate::from to be used in parsing context is rather suboptimal. But Time4J-types don't need the format engine of JSR-310 at all. Instead they should use the superior alternative ChronoFormatter as much as possible.

MenoData commented 9 years ago

Solved for v4.0. The main solution consists of several conversion constants in the central entry point TemporalType. Finally some static from(...)-methods were added to the four basic types and the class net.time4j.Duration as short-cuts (but always with concrete parameter type instead of using TemporalAccessor or TemporalAmount!).

MenoData commented 9 years ago

Update: The type conversions will be lenient regarding these two details.

Leap seconds will be ignored (corresponding to ignorant behaviour of java.time.Instant)
T24:00 (midnight at the end of day) will be mapped to T00:00 (following the parsing behaviour of LocalTime)

MenoData commented 9 years ago

Now the type conversions are more lenient. They are also used via the adapter interface ThreetenAdapter, see issue #217