Hello Donal For the DEISA and general Grid accounting systems you just want to add amounts from different accounting systems. Of course I am in control over what I produce, but I have to interpret and use what others produce, and I don't want other systems to give the possibility to add uncertainty where it is not needed. With the 6 decimal digits for seconds I meant 6 decimal digits after the dot and a arbitrary number of digits before the dot just as this was specified in the ISO8601. Regards Bart Heupers, HPC Advisor 31 (0) 20 592 8071 SARA, Kruislaan 415, 1098 SJ Amsterdam -----Original Message----- From: ur-wg-bounces@ogf.org [mailto:ur-wg-bounces@ogf.org] On Behalf Of Donal K. Fellows Sent: donderdag 21 september 2006 10:20 To: Mailing List for UR-WG Subject: Re: [UR-WG] Comment on duration format for WallDuration andCpuDuration 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. -- ur-wg mailing list ur-wg@ogf.org http://www.ogf.org/mailman/listinfo/ur-wg