|
Boost : |
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk