Hi Am 2026-06-22 17:35, schrieb John Bafford:
Personally, I'm on the fence about negative durations, since it's an unphysical concept, but allowing negative values makes calculations easier. For example, by allowing (allowedDuration - actualDuration) where allowed < actual.
Yes, this matches my thoughts on the matter exactly. Negative durations don't make sense as a concept, but they will inevitably come up in the future when calculating differences between instants. See also the “design considerations” section of the RFC.
Given that prior art, I would propose that the Duration class be changed to store 128-bit attosecond counts as well. Although no specific rationale is given in the Swift Evolution proposal, I expect that it's because modern cpus are capable of sub-nanosecond precision, which means nanosecond-precision is _already_ lossy today, and attoseconds are such a hilariously small unit of time that they allow for quite ample future-proofing. (1 attosecond == 10^-18 s; if I did the math right, a signed 128-bit attosecond count gives a time range of ±5.39 trillion years, over 750x the age of the universe.)
Attoseconds will not work for PHP, because you need 60 bits to represent the number of attoseconds in a second, which would *just* work for 64-bit versions of PHP, but not work for 32-bit versions of PHP. And of course even for 64-bit versions of PHP, we would need to preserve the seconds + subseconds split. See also the third paragraph of the “design considerations”.
Given that the representation exposed to userland necessarily needs to be split into two fields, using a sign-magnitude representation was a deliberate choice that makes working with Durations nicely symmetric.
Best regards Tim Düsterhus
