I think we overcomplicate duration by even talking about seconds. Unless someone can claim a more specific requirement, we need only to represent days, months, and years.  

And I need to ask a fundamental question about duration and our requirements:

Is there a need to represent standalone duration - as opposed to contextual duration, i.e. as in an interval represented as start/duration?

For example:  

"2 years" makes sense, it means just that "2 years", you cannot determine the precise number of days in that expression but that's no reason to exclude that representation.   

But is "2 years, 5 days" really meaningful?  This expression would have "day precision" (as Ed might say) and so it should be possible to determine the number of days.

HOWEVER, it would be possible to determine the exact number of days if that expression were in an interval: thus the interval beginning on January 1, 2009, with duration 2 years 5 days, has precisely 735 days (because we know none of the years in the interval is a leap year).

Similarly (and less trivially) for month:  "six months, ten days" does not seem meaningful as a standalone duration but is meaningful if you know the start month (and year).

So, the normalization rules would be different for a standalone duration than for a contextual duration.

So before proceeding, I ask again, does anyone see a requirement for standalone duration?


> -----Original Message-----
> From: Discussion of the Developing Date/Time Standards
> [mailto:[log in to unmask]] On Behalf Of Saašha Metsärantala
> Sent: Tuesday, July 12, 2011 2:01 PM
> To: [log in to unmask]
> Subject: Re: [DATETIME] duration normalization rules
> Hello!
> > > I consider that the W3C did a good job about these questions when
> > > reworking XML Schema 1.0 to XML Schema 1.1 and I suggest to find
> > > inspiration from the concept of "two-property tuples" for durations
> > > as of XML Schema 1.1.
> > for duration normalization rules,
> Here, I will try to summarize what is relevant for our purposes. Leap
> seconds are NOT taken into account. Durations are assumed to begin and
> end within the same time zone offset. I also assume a Gregorian
> calendar.
> Duration is often measured with the SI unit "second" and its multiples.
> In our context, we want to be able to express (calendar) years, which
> may have different lengths (in seconds).
> A (calendar) year has, though, always the same length in months, namely:
> 12 months. Months (and thus years) have different lenghts (in seconds),
> though.
> In XML Schema 1.1, this problem is solved throught the "two-property
> tuples" for durations. In other words, there are two different units of
> measurement for duration: seconds and months, each of which have their
> multiples, thus enabling c14n as:
> 60 seconds = one minute
> 60 minutes = one hour
> 24 hours = one day
> And for months:
> 12 months = one year
> Seconds and months are only partially ordered: One month is always
> longer than 27 days (2332800 seconds) and shorter that 32 days (2764800
> seconds).
> We can NOT order one month vs 30 days. Partial ordering is described in
> detail in
> second but maybe we do not need to focus on partial ordering.
> In other words, duration is two-dimensional. One dimension is expressed
> in seconds whereas the other dimension is expressed in months. We can
> partially compare these two dimensions, but we can not translate any of
> them to the other one.
> Every duration could be written with nothing more than seconds and
> months, such as:
> P123MT1234S which may be rewritten
> P10Y3MT20M34S according to the c14n above. But
> P3M is NOT expressable in seconds (or its multiple: days).
> I hope this mail brings some clarifications.
> Regards!
> Saašha,