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