[threeten-dev] ISO8601 durations and java.time

[Douglas Surber]

There is a big difference between a Period of 2 hours and a Duration 
of 2 hours. Adding a Period of 2 hours to 01:00 will always yield 
03:00 while adding a Duration of 2 hours might yield 02:00, 03:00, or 
04:00 (or something else) depending on daylight time. So the question 
is, is there any use case for adding a period of 2 hours in local 
time.

Most the use cases I have thought of are better expressed in UTC with 
conversions to local time as appropriate. Because leap seconds are 
finessed  there is no difference between Duration and Period in 
ZonedDateTime (for days, hours, minutes, seconds).

The closest thing to a use case I have come up with is a parking 
garage. Suppose parking is $20 per 24 hours or fraction thereof. I 
park my car at 10:00 on Saturday and pick it up at 10:15 on Sunday. 
Is that more or less than 24 hours if Sunday had daylight time change 
of -30 minutes? Using a Period of 24 hours it (arguably) is more than 
24 hours but with a Duration of 24 hours it is clearly less. I think 
even in this case most people would apply the Duration interpretation 
and say it is less than 24 hours. (Well except for the attendant.)

Douglas


At 06:18 AM 9/12/2013, roger riggs wrote:
>Hi Klaus,
>
>Can you remind me of the use cases?  Something like 2 years 3 months 
>1 second
>would seem like a work around for some other problem.
>I would also be interested to know how the support in XML or 
>PostgreSQL
>for date and time periods is used in practice?
>
>Roger
>
>
>
>On 9/12/2013 6:21 AM, Klaus Malorny wrote:
>>
>>
>>Hi,
>>
>>recently I took a first look on the new API that comes with Java 8 
>>and discovered something that puzzles me, namely, that there does 
>>not seem to exist a class that can fully represent ISO8601 
>>durations. "Duration" does not understand months and years, while 
>>"Period" does not understand hours, minutes and seconds/fractions. 
>>I have read somewhere about a distinction between a "human" and a 
>>"machine" time line, and for the latter, it may make sense for not 
>>having months and years, but not for the other for not supporting 
>>durations below a day.
>>
>>I consider not having a class representing ISO8601 durations as 
>>problematic, as these appear here and there in the real world, for 
>>example in XML schemas* or in databases (e.g. PostgreSQL supports 
>>something like). One would have to manage this as a pair of 
>>Duration and Period, and would need to have a custom parser and 
>>string conversion. But maybe I simply misunderstand the API. I 
>>looked into the mailing list archive for the recent months, but I 
>>did not find any discussion about it, so I just joined the mailing 
>>list to ask about.
>>
>>Regards,
>>
>>Klaus
>>
>>
>>* I also cannot see any interaction of the new API with the 
>>javax.xml.datatype.Duration class
>