On Fri, Jun 19, 2026, at 11:26 AM, Marc B. wrote: > Thanks for being this up. I think that's a sensible approach and can be > used as a starting point for further improvements to the date/time API. > > Some comments though:
> 4. You have some operator methods defined (+add, -sum, /multiplyBy, > <>=compare, what about other operators? What would those be? Personally I'd want to see operators for add and sub, at least, but I'm not sure what else would be useful. > 5. Did you thought of supporting float on the initializer methods? Floats introduce all the complexity and lack of precision of, well, floats. Best to avoid them. > 6. You should at least mention that this class works with a fixed > definition of e.g. how long a minute is - no leaps tz handling here. > Which is the correct approach for it. > > 7. Naming consistency ... add/sub vs. multiplyBy. Why not > addBy/sub[tract]By or multiply to be more consistent? I concur here. > 8. negative vs. isNegative > > 9. negate() I would expect to get back a negative Duration. Also, it > sounds like modifying the duration but I'm assuming a new instance gets > returned. What about inverted()? Good point. negated() would be fine, I think. (As noted elsewhere, sort() vs sorted() is a very common pattern for "modify in place" vs. "make new", across a number of languages.) --Larry Garfield
