This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
In brief: it's not possible to add two durations and get a third one, at least not without knowing one end point of the duration. For instance, if we try to add them as a "cartesian product" d1 = (3 months) * (10 seconds) d2 = - (2 months) * (11 seconds) d1 + d2 = (1 month) * (-1 seconds) where the result is invalid. It might be possible to meaningfully "add" it to a 'dateTime' by first moving forward a month and then back a second, but it cannot be printed. We could try to rectify this by assuming a month is 30*24*60*60 = 2,592,000 seconds and borrowing so that d1 + d2 = (0 months) * (2,591,999 seconds) but obviously the assumption that our 1 month has exactly 30 days is bad. The driver for this "bug" is somewhat extracurricular in that I would like to have additive group semantics on 'duration's which is not actually mandated by the standard. I'd imagine that many people treat 'duration's as being additive already, actually, so this could cause a subtle bug. The real clincher however would be to be able to treat 'duration's as the additive group underlying 'dateTime's as an affine space. This provides great semantics such as, for any three 'dateTime's 'dt1', 'dt2', 'dt3' we could have dt2 - dt1 = dur21 dt3 - dt1 = dur31 dt3 - dt2 = dur32 dur21 + dur32 = dur31 where 'durXX' are all 'duration's. One potential fix for this would be to remove the restriction that ensures the polarity of the months and the seconds components of a duration are the same. This would enable the "cartesian product" additive group definition. It would require (at least) an extension to the lexical space to include the distinction between "globally negative values", "month negative values", and "second negative values".
It is a fact about the Gregorian calendar that arithmetic on durations expressed as numbers of years, months, days, hours, minutes, and seconds is not necessarily precise. Life is hard. It does not seem to me to be the task of XSD to repair this fact, so the inability to perform arbitrary arithmetic operations on durations without running into quandaries like the ones described does not seem to me to be a flaw in the XSD spec. There are two simple workarounds: work only with positive durations and addition, or work with the two subtypes of duration for which arithmetic is easy and deterministic (namely those consisting solely of year and month or solely of day, hour, minute, and second -- these are deterministic for arbitrary arithmetic, as long as it is agreed that leap seconds do not participate in the date or duration arithmetic). In allowing negative durations, XSD is already extending ISO 8601 (following here, as far as I can tell, the lead of SQL and of Java); allowing different signs on different parts of a duration would be an ingenious solution to the problem you have encountered, but it would make XSD incompatible with XQuery and with other users of ISO 8601 durations. That does not seem to me to be a good idea. So I would recommend that the responsible W3C working group decline to make any change in XSD here, and respectfully suggest that they close the bug report with a resolution of INVALID (since XSD does not in fact define operations for its simple types) or WONTFIX.
I agree that it is difficult to perform operations on dates and times—as you noted, it's very difficult to do anything throwing away leap seconds for instance. Additionally, the solutions you suggest are both undoubtedly workable. If this is marked as WONTFIX then I truly have no qualm. I raised the issue because extending 'duration' to include negativity while maintaining the interaction between the month and second components destroys structure. Even if it follows in the stead of SQL and Java, I found it surprising while reading the specification.