If we're offering UTCClock.sleep(), or equivalently allowing Task.sleep() on a UTCClock, how do we cope with time adjustments?
Using UTC does free us from the troubling issue of daylight saving time, but what if we do a sleep() and either NTP or the user adjusts the system clock? Equally, what if leap seconds are added or removed?
Is there a guarantee that we will never wake early? i.e. if we ask to wait until 5am UTC, there is no circumstance under which we will find ourselves woken up at 4am UTC? (Obviously there's a race condition here — if we wake at what is currently 5am UTC and the user immediately moves time back an hour, that's another thing — but do we guarantee that, for instance, if the user moves time back an hour, we won't inadvertently then wake at the wrong time)?
I also share the concern about calling Date(timeIntervalSinceReferenceDate: 0) systemEpoch. That is true on Darwin. It isn't the system epoch on other platforms, and I would, like @compnerd, expect January 1st 1601 on Windows and January 1st 1970 on UNIX more generally.
We could maybe have foundationEpoch or even just epoch and set that to Date(timeIntervalSinceReferenceDate: 0), then systemEpoch would be the native epoch of the system on which we are running? That would actually be quite useful as it would provide the relevant constant for converting timestamps from the system native representation.