Upon thinking about it a little more, I actually have a stronger opinion that it's probably not ideal to try to assign direction to durations themselves, and even then making them signed wouldn't be the best way. A duration is a scalar length measurement in the time axis. Those things are always positive, at least in our universe. I don't think we gain much by pretending otherwise, and I think we lose clarity.
Expressing a before/after relationship requires that we establish what is the anchor point. Is it the present time experienced in my reference frame? Is it unix epoch? Using a negative number to denote a disembodied "duration before" leaves me guessing about the anchor. In the case when we want to express the timestamp "3 days before/after time t0" I think it's probably best to say something like:
This isn't a criticism of your library, it looks awesome and I'll definitely use it. I am fairly surprised that negative duration definition made it into the standard though.
There are `checked_add` and `checked_sub`. But that shifts the "direction" of the span to the operation, which is a static property of your program, instead of being part of the value itself, which is a dynamic property of your program. I think this results in more annoying code where you just wind up carrying a sign around anyway.
There are also negative years, even though that doesn't really correspond to anything "real" either.
Expressing a before/after relationship requires that we establish what is the anchor point. Is it the present time experienced in my reference frame? Is it unix epoch? Using a negative number to denote a disembodied "duration before" leaves me guessing about the anchor. In the case when we want to express the timestamp "3 days before/after time t0" I think it's probably best to say something like:
This isn't a criticism of your library, it looks awesome and I'll definitely use it. I am fairly surprised that negative duration definition made it into the standard though.