Hi
On 2026-07-14 10:45, Pierre Joye wrote:
> - it is awkward to have nanoseconds in setSeconds out of nowhere. I
> understand some external factor (other entities) leading to that
> decision but that creates illogical, inconsistent and confusing
> semantic boundaries. A box can contain apples does not mean
> setDimension should use apples with a limit on top. Or an apple can be
> used with a box that does not make an apple's unit in square feet.
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”.
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.
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>`).
inconsistency of having nanoseconds, and only nanoseconds, on top of
that makes it worse.
Best regards
Tim Düsterhus
