Comment 4 for bug 969928

I think you want to raise NotImplementedError; not NotImplemented.

I agree that there is some ambiguity between static times (days, hours, etc) and dynamic times (months, years). This already exists in __eq__ where 28 days is not equal to 1 month. It's also unclear what it means to add 1 month and 1 day to a datetime because it's not commutative.

One solution would be to assert that within a relativedelta static and dynamic times cannot be mixed within the same relativedelta. This would solve the ambiguity that exists between adding relativedelta(months=1, days=1) to datetime.datetime(2012, 2, 28): a month and a day could be added as distinct relativedelta objects to a datetime and it forces the user to explicitly set the ordering.

Going by this scheme, you could then raise NotImplementedError when comparing static and dynamic times, but still yield a sensible answer when comparing relativedeltas which contain static times.

Whether it makes sense to compare years and/or months can be explored at some point.

This could be a breaking change for some people. But I think it's an improvement because it doesn't seem to be reasonable to rely on relativedelta(months=1, days=1). If you think it's an good way to proceed let me know and I'll whip up a patch. I've implemented it in my forked version already.