[threeten-dev] Hypothetical Period/Duration change

[Douglas Surber]

Duration and TimePeriod seem different to me. Let N be a 
ZonedDateTime for noon March 9, 2013 Americas/Los Angeles. 
N.plus(aDurationOf24Hours) would result in a ZDT of 13:00 March 10 
while N.plus(aPeriodOfOneDay) would be noon March 10. Duration is 
physical time, a number of SI* seconds. Period, and by extension 
TimePeriod is field based and divorced from physical time. Using a 
single class TimePeriod for both concepts--one day and 86,400 SI 
seconds--seems confusing.

WRT JDBC, ANSI SQL has two INTERVAL types, YEAR MONTH and DAY SECOND. 
Values of those types are normalized to have 60 seconds/minute, 60 
minutes/hour, 24 hours/day and 12 months/year. So an INTERVAL DAY 
SECOND is a number of SI seconds and appears to match Duration pretty 
well. INTERVAL YEAR MONTH doesn't have days so doesn't exactly match 
DatePeriod. Personally I'm not concerned about an exact match between 
Java and SQL types. My vision for using Period in JDBC was to do a 
copy between the INTERVAL fields and the Period fields. It would be 
an error to write a Period where the fields were not in canonical 
form or contained an unsupported combination of non-zero fields. This 
approach works equally well for DatePeriod/TimePeriod.

I'd prefer to leave things as they are.

Douglas

At 07:35 AM 1/30/2013, Stephen Colebourne wrote:
>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