From: Jeff Garland (jeff_at_[hidden])
Date: 2004-05-11 13:05:19
On Tue, 11 May 2004 17:45:43 +0200, Daniel Krügler wrote
> OK, I understand the nature of the problem here. And probably it
> wouldn't help, if ISO 8601 would define a month in this context,
> would it? Regrettably I have no access to the full 8601 spec, but
> does anyone have?
I have seen it and it doesn't discuss the semantic issues associated with
such a representation -- only how it should be formatted as text.
> Lets assume, that ISO 8601 would provide a
> resolution, would it make sense to make such an iso_... function
> available (Because it would depend on a special calendar definition)?
I have no problem adding the parsing, but there needs to be something to
parse to. I have some experimental code that will likely become available in
the future that represents months and years as a 'logical duration' type
that is different from the 'physical duration' types. You can then imagine
a structure like:
struct logical_duration
{
logical_duration(years y, months m, days d, ...etc...);
private:
months month_count; //years just convert to months by multiplying by 12
time_duration time; //physical duration of all the other parts
};
Then a duration like this could be parsed into this structure and then would
provide for the usual interactions with the other classes in the library.
For example:
logical_duration ld = from_iso_string("P18Y9M4DT11H9M8S");
ptime t += add_with_end_of_month_snap(t, ld);
And since none of this is in the library currently, I'd like to hear any
details of your use case that you can share...
Jeff