[threeten-dev] Hypothetical Period/Duration change

[Stephen Colebourne]

On 30 January 2013 15:25, Roger Riggs <Roger.Riggs at oracle.com> wrote:
> The mapping of SQL INTERVAL requires a mapping to a Java type;
> currently Period fills that function.  INTERVAL never mixes years and
> months
> with days and time.  (Douglas pointed this out in email from 12/7/2012
> "Period")
>
> If we have two types, the mapping map be difficult for developers to
> manage
> though Douglas may be able to see a way.

My understanding is that this change would be beneficial to SQL/JDBC.

Their YEAR/MONTH concept would map to DatePeriod.
Their DAY-TIME concept would map to TimePeriod.

This change is dependent on JDBC agreeing to this.

> We might take on the restriction from SQL that Period cannot be used
> simultaneously
> used for both purposes. Adding the restriction to Period could be simpler,
> and Duration removed.

Having two classes is not the problem here. Having two classes where
it is unclear as to the purpose of each class is.

Restricting the state of the current Period class in weird ways that
are difficult to describe is not something I find appealing.

> It would not provide the compile time type difference between machine time
> and human time.  But the difference in behavior and semantics comes
> from the type the duration/period is applied to.
> Instant, LocalDate, LocalTime, OffsetTime, OffsetDateTime all treat Period
> as
> a Duration.  Only ZonedDateTime has any ability to deal with the TZ data
> variances and that could be addressed with different methods on ZDT to
> handle the two cases, adding machine time vs adding human time.

This is sort of correct, but Duration cannot hold year or month.

We've arrived at the TemporalAmount interface, and I think we should
stick with that now. It will scale OK with two implementations. Having
two methods to do different things is less flexible than using the
interface.

Stephen