Yea, there are MANY others I could have listed but I focused on Go, Rust and Kotlin as three spiritually similar languages. Obviously std::chrono is a good example of a commonly used clock based system and was one that I did consider when researching this (the pitch was already long as it was so I decided to keep it smaller)
That package seems more focused upon wall and human interacting calendrical calculations - this is heavily focused upon execution. They are not mutually exclusive and that package can totally exist on its own, this however is posed for integration to Task and other concurrency needs.
Clocks are un-inhabited types (for the default ones) so I am not sure what stride of that would be.
Yep that is the proposed behavior (but they are NOT numeric)
This was one point that the resident Darwin time experts urged me ensure this was very explicit of a conversion function. @rokhinip perhaps you can chime in here on your thoughts? But these functions do a lossy conversion that is failable.
Absolutely! As a matter of fact I think there may be clocks defined at numerous layers beyond the swift standard library/concurrency library layers. But the compromise for ergonomics was to specifically keep the nanoseconds duration type as a concrete type (to avoid the common cases being complex). Any custom clock will still have to deal in that as a currency type. But that feels accomplishable for even exotic clocks like a "manually incremental" clock.
The concept of day accounts for with most people a calendrical day. E.g. when I say 5 days from now, I mean 5 calendar days, where if that includes a leap hour or leap day that is part of how it is read from a calendar. I think like other APIs we should guide developers into making appropriate choices (and even hours is perhaps a trap to that extent).