What is your evaluation of the proposal?
+0. Time is hard
Does this proposal fit well with the feel and direction of Swift?
For the most part. It is unfortunate that the most useful clock (
UTCClock) for interacting across the network is in Foundation; this makes it likely we will see several different implementations of system clocks, possibly referencing the same underlying system API, each used within portions of a larger application by global reference.
This AFAICT is done to enable use of the Foundation-defined
Date type, rather than a new more-accurately named type which is also convertible to Date/NSDate. However, the ramifications are that other time and calendaring features will likely be excluded from foundation in the future. I'd still far prefer e.g. a
My interpretation of this proposal is that a
Clock defines a unit of measurement of time of some sort - atomic time, UTC time with omitted or duplicated seconds, UTC with elided seconds, local system uptime, system non-suspended runtime, individual CPU uptime, frame count, etc.
Duration should not be a concrete type if it is not measuring a single thing. It appears that Duration is being used to represent each of continuous time, suspended time, and UTC time. Would my task
sleep(for:) 100 continuous seconds, 100 non-suspended seconds, 99 seconds because or a negative leap second, or possibly just a single second because the system clock got updated at a poor time?
That Durations are unit types is illustrated by the called-out lack of multiplication. But the actual unit of the concrete
Duration type is unspecified and different per clock and per platform. The Clock and Instant protocols allow for specific durations to be present for specific units, and that should be leveraged more - even if just by wrapping the internal Duration type for these cases.
(Of course, the clock Duration itself may be defined in terms of a mix of units - e.g. a nanosecond may be atomic nanoseconds while the seconds are UTC seconds, and one second could potentially contain zero or two billion nanoseconds. Time sucks.)
This proposal only defines Clocks in terms of locally measurable terms. The lack of a stable cross-platform unit of measure means that Clocks themselves need to have their own source of measurements (e.g. a local synthetic or hardware basis). I could define a
TAIDuration easily enough, but a TAIClock would require going significantly beyond what is supplied in this proposal, with per-platform behavior.
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
While there are several parts of the Swift proposal which I like above the Java JSR 310 specification, I would point to the definition of Instant in that specification as an example of what I would like to see documented for e.g. UTCClock.
Note while the Java approach is simplified (it only defines the one Clock/Instant/Duration behavior, vs ), the ability to read the equivalent to UTC Clock and all other temporal operations such as calendaring are part of the always required
java.base module, vs being broken out into a separate
time module and excluded for e.g. compact/embedded profiles.
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
It felt like a fair bit, but time is relative and the interaction of time standards relatively insane.