[threeten-dev] Hypothetical Period/Duration change

[Stephen Colebourne]

On 30 January 2013 14:16, Stephen Colebourne <scolebourne at joda.org> 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

I've attached what a DatePeriod might look like.

Stephen