[UR-WG] Comment on duration format for WallDuration and CpuDuration

Donal K. Fellows donal.k.fellows at manchester.ac.uk
Thu Sep 21 03:20:02 CDT 2006


Bart Heupers wrote:
> If you want to convert this into seconds, or add this kind of
> duration to a grand total it is unclear how long a month is or a
> year. Is a month 30 ,31 or 28 days ? And a year is that 365 or 366
> days?

It is a feature of that ISO spec that you can use arbitrarily large
numbers for any field in durations. This is important because of
precisely this issue; there is no way to automatically convert from some
count of seconds to larger units. This is because, as you know, neither
a year nor a month is not a fixed length. Nor are days (think daylight
savings differences!) or even minutes for that matter (because of leap
seconds, though they're usually glossed over). The correct thing to do
in this case is to record the quantity of time units that you're
actually recording in the ISO format, like this:

   PT12345S     - 12,345 seconds
   PT76,25H     - 76 and a quarter hours (this probably ought to be
                  recorded in minutes though, I admit)
   P500DT       - 500 days

Don't try to "normalize" this value though; as this discussion shows,
you cannot do that correctly. (Indeed, the reason why I favour the ISO
8601 duration format is that it allows the accurate capture of such
granularity information.)

OK, this can lead to some oddities when you add them together:

   P20DT100000S - 20 days and 100,000 seconds, i.e. somewhat over 21 days

but that can't be helped. If you're adding amounts from the same basic
accounting system (which will be the usual case I expect) then I don't
expect this to be a real problem; the granularity will be the same.

> The use of years and months in this representation only give rise to
> needless uncertainties.

Remember, you are in total control over what you produce. If you put
uncertainties in, you only have yourself to blame.

> Therefore I think it is better to use as duration format the number
> of seconds, with six decimal digits, or of you still want to use the
> ISO8601 standard, use it with the restriction that years and months
> will never be used. In that case it is always possible to convert it
> unambiguously to seconds.

As noted above, the ISO standard is a great deal more flexible than you
believe. And your proposed requirement to use 6 decimal digits for
seconds would suck; a job that ran for a fortnight (yes, they do happen
in production workflows when serious amounts of data are in use) would
overflow this, since a million seconds is only a bit over 11.5 days. :-)

Given that a spec exists and using it (through xsd:duration) is easy,
and additionally that your replacement has its own subtle set of gotchas
and would also convey less information to the casual observer, I
advocate going for what we have. It also means we don't need to do
another spec revision. :-D

Donal.


More information about the ur-wg mailing list