[UR-WG] Comment on duration format for WallDuration andCpuDuration

[Rosario Michael Piro]

Hi all!

Carl Wright wrote:
>  ...
> Having said that, I can think of times when days, months and years are used in billing. In this context billing refers to the whole charges for a period of usage (day, month, ...). Rating (charging) refers to the charge for a specific event of usage/service. The situations that are day-friendly are usually in situations where you have memberships, rights, or other relationships. These come with increasing complications in the calculation of charges. You then have to have pro-ration algorithms when you have mid-period start and stops of these relationships. Just look at what happens with your wireless bills.
> 

That's a good observation. It depends on what precision you need and 
what are your methods of billing/charging.

I like the approach taken by the APEL developers that have, in their 
accounting record table (inspired by the GGF UR, but not compliant to 
it), columns for both an ISO8601 version of Cpu/WallDuration, as well as 
a version in seconds. The UR as well might have the possibility to 
specify both formats, such that each application/accounting system can 
choose on which to rely upon.

> If you expect that you are charging for relatively short durations, make your life much easier by using hours, minutes and seconds.

Well, looking at some use cases we most probably can rely upon that. 
Above all if we are seriously thinking about some kind of aggregate 
usage records.


Donal K. Fellows wrote:
 > 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.

That's actually what I was trying to figure out. On the ISO website I 
found only information on the basic ISO8601 specification that covers 
only date and time, time periods and durations are handled by some 
extension (as far as I know), but I couldn't find any exact 
specification (if you have some pointer I'd appreciate it). The basic 
ISO8601 specification wouldn't allow arbitrary numbers of days, etc. to 
be specified, but it does make sense for time periods.

 > ...
 >> 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.

Yes and no, think about interoperability between different accouning 
systems and maybe even Grid environments (that's exactly what we're 
working within the OMII-Europe project). I can make sure that I use only 
unambiguous specifications, maybe even only the number of seconds. But 
if the UR standard allows to specify also days, months and years, then I 
will need to be able to handle them ... the question is just: how? If I 
will not be able to handle them, then I will have to refuse URs coming 
from another systems, let's say OSG, if they handle things in a 
different way ... which obviously undermines all standardization efforts ...

Cheers,

Rosario.