Re: [RFC] Duration class

On Thu, Jul 16, 2026, 8:57 PM Tim Düsterhus <tim@bastelstu.be> wrote: > >> As outlined above, I believe this special casing of the “subsecond > >> boundary” is common in the real world and human communication. > > > > The human communication part is how the Duration provides its > > information. That's not correlated to how they are or can be provided. > > It is just as common in the real world to have duration information in > > one unit only and decimal. F.e. 234.54ms. or 3.4 hours, etc. the > > I'm not typically seeing decimals being used for units smaller than > seconds. 234.54ms would typically be communicated as either 234_540 > microseconds with an explicit ±10 microseconds to indicate the number of > significant figures, or as 0.23454s. But this might be another case of > “we made different experiences and thus feel the design should be > different”. > I think we are in different realities ;-). More seriously, and some random weekly internals on reddit made me realize my point was not maybe not clear. It appears to me that you confused displaying, reading properties from a duration and how it is created. And thr the limitation to unit per higher unit is cumbersome at best, annoying at worse. Counter intuitive and bad UX.. > > Allowing the latter would effectively be a floating point > representation, which is planned to be supported as an input for future > scope. It needs some more thought than the fixed-point (seconds + nanos) > decimal, because of the finite precision of IEEE-754 double precision > representation. > sure, but having nanoseconds to fromSeconds is fine ;-). Having floating points (all units) is not really about the IEEE-754 precision, while important, but more about use cases. Is a duration a precision timer too? if yes, then it will be needed and precision can be taken care of up to, or down to, a certain level. If it is not, we should not bother. UX is more important in that case. > > > set<Unit> method can extremely easily handle this. And the > > Small terminology note: There are no, and will be no setters. There's > just the named constructors (from<Unit>). > Right, typo, I meant the from<Unit>.