Apart from the criticisms of the naming and design of
Date, which I generally agree with, the proposal has editorial issues that make it hard to understand what it means, particular in the Definitions section.
Absolute Time: Time that always increments, but suspends while the machine is asleep. The reference point at which this starts is relative to the boot time of the machine so no-two machines would be expected to have the same uptime values.
This is presented as if it was some sort of universal or neutral terminology, but as far as I know it’s Mach-specific – which is fortunate, because it’s an absurdly bad name. If “absolute time” meant anything, it would be a time scale that’s exactly the same everywhere, but no such thing exists, as famously proven by Einstein.
Luckily, this definition is only referenced in the definition of Darwin/BSD uptime, and can be removed.
Monotonic Time: Darwin and BSD define this as continuous time. Linux, however, defines this as a time that always increments, but does stop incrementing while the system is asleep.
Uptime: Darwin and BSD define this as absolute time. Linux, however, defines this as time that does not suspend while asleep but is relative to the boot.
Firstly, monotonic time has a clear and specific meaning: it’s time measured by a clock that can only advance, never regress. Whether it pauses when the machine is asleep is an orthogonal property.
Secondly, if we untangle these definitions it seems that the distinction between “uptime” and “monotonic time” on Linux is exactly the opposite of what it is on Darwin and BSD. The proposal then goes on to define
UptimeClock in alignment with the Darwin/BSD definitions, but without explicitly referring to the definitions or motivating this choice.
Naming these clocks, with their subtle distinction, based on the usage of a subset of platforms, where swapping them around would make just as much sense, seems like a poor choice. If we want these clocks to have precisely defined meanings, that should be reflected in meaningful names (like
SuspendingMonotonicClock). If we have a clock named
UptimeClock, it should follow the platform convention for uptime, but such a thing should probably be in a platform-specific module rather than the
Further down, we have:
They are distinctly NOT
Numeric due to the aforementioned issue with regards to multiplying two
TimeInterval variables. That being said, there is utility for ad-hoc division and multiplication to calculate back-offs.
There is no aforementioned issue; these two sentences are the only mention of multiplication in the prose. (That said, I agree that multiplication and division should only be allowed with scalars.)
no more than 1,000,000,000 nanoseconds (which is 29 bits)
30 bits (well, 29.897 or so).
Under Alternatives Considered:
It has been considered to leave the Duration type to be a structure and shared among all clocks.
Since this is the direction taken in the proposal, it shouldn’t be in Alternatives Considered.
Date.init(converting uptimeInstant: UptimeClock.Instant) intended to be defined? As far as I can see, implementing it accurately would require a log of all the times the machine has been suspended for as long as the process (or any Swift process on the same machine that it might RPC to) has been running.