Fully agree. Swift is still quite a young language, so it's really important we get time right the first time so as to not fracture Swift 20 years from now once it has reached global domination (I say this half-jokingly).
IMO we cannot in good faith push for ownership control / performance annotations, which are in part aimed at expanding Swift's use in embedded systems, while forcing users to import a big monolithic >10mb library just to get the current date or get the time in Paris.
I understand that one could say this about just about anything in Foundation – for instance JSON en/decoding is essential for embedded systems using JSON-RPC – but I do sincerely think that Time is just that important. Much like @hassila above, I don't mean to belittle / depreciate the effort that has been put into Foundation, nor underestimate the role it has played in Swift's continued growth (it's played a huge role), but I don't think it's right for the role of Time in the long-run.
That's why I think swift-time would be perfectly suited for the job – its cousins have showed that these kinds of libraries do enjoy high adoption and quick yet meaningful iteration, and seems to me to be much better placed for a future Swift where importing Foundation isn't the absolute default.
Furthermore, taking a more present perspective, today swift-time would mean that all iOS/macOS developers will be able to enjoy these new, more modern and potentially more correct APIs for any OS version they target, not just the latest one – and idem for when APIs are changed / added under the semantic versioning rules.