[threeten-dev] Hypothetical Period/Duration change

[Stephen Colebourne]

On 30 January 2013 17:06, Douglas Surber <douglas.surber at oracle.com> wrote:
> 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.

Agreed that two classes are needed, one that is DST-aware and one that
is not. But this difference primarily applies to days, not hours/mins.

> 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.

I'm currently exploring the simplest option, removing the time fields
from Period, and adding some additional methods to Duraton. Current
class names to remain. This has knock on simplifications elsewhere,
which is why it is being pursued.

INTERVAL YEAR-MONTH would map to Period, DAY SECOND to Duration.

Stephen