[threeten-dev] Hypothetical Period/Duration change

[Roger Riggs]

Stephen,

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.

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.

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.

Roger


On 1/30/2013 9:16 AM, Stephen Colebourne wrote:
> Its late in the JDK 1.8 process, so there is no guarantee that this
> change could actually happen. However, it is worth flagging up as a
> possibility.
>
> Currently we have two classes:
> - Period = YEARS, MONTHS, DAYS, HOURS, MINUTES, SECONDS, NANOS
> - Duration = SECONDS, NANOS
>
> As well as the difference in the fields they hold, they have different
> semantics in terms of how they operate at a DST change. A Period of
> one day will add 23 or 25 hours at a DST change, whereas a Duration of
> one day will always add 24 hours (because it doesn't actually hold
> days at all).
>
> This model is inherited from Joda-Time, and I've presumed it necessary
> until recently.
>
> However, looking at this right now, it seems that this approach
> results in a lot of duplication of methods and concepts for perhaps
> questionable use cases. Do users really need to store both date and
> time parts in the same object?
>
> The hypothetical option would be as follows:
> - DatePeriod = YEARS, MONTHS, DAYS
> - TimePeriod = DAYS*, HOURS, MINUTES, SECONDS, NANOS
> Both classes would be stored fully normalized, so 15 months would
> always be seen as P1Y3M.
>
> Where DatePeriod handles DST change and TimePeriod ignores it. (The
> DAYS* "field" in TimePeriod would be exactly 24 hours always)
>
> This is a relatively radical change conceptually, but is very logical
> and not that large in the codebase. It mostly involves renaming Period
> to DatePeriod, Duration to TimePeriod, deleting methods on DatePeriod
> and adding a few methods to TimePeriod.
>
> I've asked around my company OpenGamma, and no-one can think of a use
> case where it makes sense to store "6 months and 5 hours". If you do
> want this, then storing both objects or writing your own class is not
> too much of a hardship. My questioning also revealing a lack of
> clarity about the meaning of the two classes, again suggestive that
> change would be desirable.
>
> So, **opinions please** on whether this is a good idea or would be a
> problem. (Ignore the aspect of whether it is too late for the moment).
>
> Stephen

-- 
Thanks, Roger

Oracle Java Platform Group

Green Oracle <http://www.oracle.com/commitment> Oracle is committed to 
developing practices and products that help protect the environment