[threeten-dev] Hypothetical Period/Duration change

[Stephen Colebourne]

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