# SE-0329: Clock, Instant, Date, and Duration

**URL:** <https://forums.swift.org/t/se-0329-clock-instant-date-and-duration/53309>\
**Category:** Proposal Reviews\
**Created:** [November 5, 2021, 2:30am UTC](https://forums.swift.org/t/se-0329-clock-instant-date-and-duration/53309 "2021-11-05T02:30:40Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![John\_McCall](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/john_mccall/32/1351_2.png) [@John\_McCall](https://forums.swift.org/u/John_McCall)\
**Post date:** [November 5, 2021, 2:30am UTC](https://forums.swift.org/t/se-0329-clock-instant-date-and-duration/53309/1 "2021-11-05T02:30:40Z")

</div>

Hello, Swift community.

The review of [SE-0329: Clock, Instant, Date, and Duration](https://github.com/apple/swift-evolution/blob/main/proposals/0329-clock-instant-date-duration.md) begins now and runs through November 15th, 2021.

Reviews are an important part of the Swift evolution process. All review feedback should either be on this forum thread or, if you would like to keep your feedback private, directly to the [review manager](mailto:rjmccall@apple.com). If you do email me directly, please put "SE-0329" somewhere in the subject line.

## What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

- What is your evaluation of the proposal?
- Is the problem being addressed significant enough to warrant a change to Swift?
- Does this proposal fit well with the feel and direction of Swift?
- If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
- How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at:

> [https://github.com/apple/swift-evolution/blob/master/process.md](https://github.com/apple/swift-evolution/blob/master/process.md)

As always, thank you for contributing to Swift.

John McCall  
Review Manager

---

<div class="post-metadata">

**Author:** ![Torust](https://avatars.discourse-cdn.com/v4/letter/t/f17d59/32.png) [@Torust](https://forums.swift.org/u/Torust)\
**Post date:** [November 5, 2021, 2:53am UTC](https://forums.swift.org/t/se-0329-clock-instant-date-and-duration/53309/2 "2021-11-05T02:53:37Z")

</div>

I'll save commenting on the wider proposal until I've had a chance to read through in more depth, but on the specific point of the naming of `Date`: I know it was of contention in the pitch thread and I happen to agree it's not a mistake that should be carried forward. Is there any technical reason it could not be given a new name, have a typealias of:

```swift
@available(*, deprecated) // with the correct stdlib version
public typealias Date = NewName

```

and change the Clang importer to map `NSDate` to the new name? It would remain bridgeable with `NSDate` under this scenario. Aside from a bunch of deprecation warnings in Swift code that uses `Date` currently (easily addressed by a find & replace), it seems like this would provide a fairly clean road forward.

---

<div class="post-metadata">

**Author:** ![davedelong](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/davedelong/32/38708_2.png) [@davedelong](https://forums.swift.org/u/davedelong)\
**Post date:** [November 5, 2021, 3:25am UTC](https://forums.swift.org/t/se-0329-clock-instant-date-and-duration/53309/3 "2021-11-05T03:25:20Z")

</div>

First off, I'm quite surprised this is going up for review already. There was only the single pitch thread, and (from what I saw) the public proposal text was never updated for further feedback. This review seems premature.

That being said...

**What is your evaluation of the proposal?**

**-1**. This proposal is a good start, but I fundamentally object to the inclusion of moving `Date` into the Standard Library and do not believe the proposal should move forward as long as that's part of it.

**Is the problem being addressed significant enough to warrant a change to Swift?**

Yes. The addition of the `Clock` and `Instant` types is long overdue. I also really appreciate @Philippe_Hausler's incorporation of custom clocks (and the accommodations to the various protocols to support them). Those will be _enormously_ beneficial. I'm excited to use them (and delete my own versions of them!).

**Does this proposal fit well with the feel and direction of Swift?**

Overall, mostly. The `Clock` and `Instant` additions are great and we should _absolutely_ accept those. I have two major specific concerns:

1. The presence of `.minutes(...)` and `.hours(...)` on `Duration` are going to be abused by developers wanting fundamentally different concepts. I do not think they should be there, because they look like the right thing, but might not actually be what you want. You think "ah, I want to show something to the user 3 hours from now, therefore I do `myWallClock.now + .hours(3)`, without realizing that this is usually the wrong approach to be taking.

2. `Date` should not be moved into the standard library. There is universal agreement that "`Date`" is the wrong name for the type. [Even the manager of the Foundation team concurs](https://forums.swift.org/t/pitch-clock-instant-date-and-duration/52451/191). Here, with the introduction of new timekeeping APIs, we have the opportunity to correct this, and we're instead proposing to double-down on this very confusing name.

**If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?**

In other comparable languages, the term `Date` has been eschewed entirely. Any locale-aware language prefers terms like `Moment` and `Instant` for the "instantaneous point in time" concept. The only major exception I can think of to this is JavaScript, but that's a false positive because the JS definition of a date is intrinsically tied to a Gregorian calendar. All major languages use names like `ZonedTime` or `LocalDate` for calendar-aware types.

**How much effort did you put into your review? A glance, a quick reading, or an in-depth study?**

I've been building calendaring APIs for a decade. This is basically my thing.

---

<div class="post-metadata">

**Author:** ![Tino](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/tino/32/1073_2.png) [@Tino](https://forums.swift.org/u/Tino)\
**Post date:** [November 5, 2021, 5:57am UTC](https://forums.swift.org/t/se-0329-clock-instant-date-and-duration/53309/4 "2021-11-05T05:57:32Z")

</div>

**What is your evaluation of the proposal?**  
-1 (because some details imho could be improved drastically)

**Is the problem being addressed significant enough to warrant a change to Swift? Does this proposal fit well with the feel and direction of Swift?**  
Yes; but…

**Date**  
As others already said: Let's not move a confusing name into the core of the language — it's better to fix it.  
Also, I think the conversion to `NSDate` and the loss of precision during encoding are unfortunate, and could be avoided with a new type.

**Duration**  
The description for `Date` says

> `UInt32` for nanoseconds normalized where the nanoseconds storage will be no more than 1,000,000,000 nanoseconds (which is 29 bits)

But `Duration` is supposed to use `Int64` to store nanoseconds. That makes me wonder: When 29 bits are enough to reach a full second, why use that much memory?  
Also, it has been mentioned that we might need more granularity than nanoseconds. Therefore, I would at least move away from that unit (even with `Date`, we could easily increase precision by factor four by using all available bits).  
As comparing `Duration`s coming from different clocks is discouraged, and `Clock` already has a minimum resolution, I'd go a small step further and strip all units from `Duration`, so that it's just a big integer (and `Clock` defines how many units make up one second).

**WallClock**  
I still think we need neither `Date` nor `WallClock` in the stdlib — but if it's added, I don't think the name is good:  
It has a `measure` function, but because of possible jumps, this seems to be a bad choice most of the time. Imagine someone receives the task to measure [wall-clock time](https://en.wikipedia.org/wiki/Elapsed_real_time) of some function, and has the choice to use either `WallClock` or `MonotonicClock`. Wouldn't it feel natural to measure wall time with `WallClock`?  
But doing so will lead to strange results, because `WallClock` can change any time; you could even end up with negative duration!

**Static variables**  
There has been a big improvement towards testability by moving to a model where everything is `static` to `now` being a property of each instance of `Clock`.  
However, there are still some static declarations, and I find it hard to understand the reasoning behind those. Probably it's easier without having seen the first draft of the pitch, but afaics, encouraging the use of `Instant.now` is problematic:  
Imagine you have a clock which is supposed to always return a fixed `Date`. This would be quite reasonable to mock `WallClock` in tests, but this will break silently when the `.now`-shortcut is used — because your reference point suddenly looses all connection to your custom clock.  
I think durations are more convenient than deadlines in most situations, but there are simple alternatives that neither compromise testability nor ease of use.

**How much effort did you put into your review? A glance, a quick reading, or an in-depth study?**  
Read all posts in the pitch, did some research on the terms in question

---

<div class="post-metadata">

**Author:** ![Zollerboy1](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/zollerboy1/32/12997_2.png) [@Zollerboy1](https://forums.swift.org/u/Zollerboy1)\
**Post date:** [November 5, 2021, 6:52am UTC](https://forums.swift.org/t/se-0329-clock-instant-date-and-duration/53309/5 "2021-11-05T06:52:00Z")

</div>

> [@John\_McCall](#):
>
> - What is your evaluation of the proposal?

In principle, I'm absolutely in favour of the core ideas in this proposal. However, and there I'm completely agreeing to everything already said in this review, at the current stage of the proposal, I am still -1.  
I think that this proposal moved into review phase too quickly. Yes, the pitch thread was quiet for some time now, but that would have been the perfect moment for the author to address all the issues raised with the first version of the proposal and start a second pitch phase, exploring further some details like the naming of `Date`, etc.

> [@John\_McCall](#):
>
> - Is the problem being addressed significant enough to warrant a change to Swift?

Definitely, working with time, duration and clocks has always been awkward and unintuitive in Swift, so I think that this proposal – provided my issues with it get resolved – would improve the situation significantly.

> [@John\_McCall](#):
>
> - Does this proposal fit well with the feel and direction of Swift?

Yes, but again, I have some issues with specific details of this proposal, all of which have already been raised here, so I won't repeat them again.

> [@John\_McCall](#):
>
> - If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

I have used clock libraries in many different languages, but not very extensively. Nonetheless, I would say, that this proposal overall is a pretty good solution to this problem in comparison to how it's solved in most other languages.

> [@John\_McCall](#):
>
> - How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

I did read the proposal and followed the whole pitch thread closely, however – in hindsight you're always smarter – I should have chimed in with my take on the problems with `Date` and `Duration` in the pitch thread. I thought that all the points that I could have made were already brought up by others and assumed that there would definitely be a second pitch phase where these exact issues would be explored in a more focused way, but seemingly that wasn't the case.

---

<div class="post-metadata">

**Author:** ![Jumhyn](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jumhyn/32/3891_2.png) [@Jumhyn](https://forums.swift.org/u/Jumhyn)\
**Post date:** [November 5, 2021, 12:47pm UTC](https://forums.swift.org/t/se-0329-clock-instant-date-and-duration/53309/6 "2021-11-05T12:47:29Z")

</div>

@davedelong has pretty much covered everything I wanted to say and more—I’m also -1 for the reasons discussed.

The only thing I’ll add is that between the pitch and the beginning of this review thread, I encountered _yet another_ DST bug caused in part by an assumption that `Date` would handle calendrical concerns like DST ‘magically’. These are mistakes that experienced programmers make, enabled in large part by the fact that `Date`‘s name plainly misrepresents its functionality.

I’ll also explicitly +1 the suggestion that convenience methods for `.hours` and `.minutes` be removed.

---

<div class="post-metadata">

**Author:** ![bjhomer](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/bjhomer/32/313_2.png) [@bjhomer](https://forums.swift.org/u/bjhomer)\
**Post date:** [November 5, 2021, 2:19pm UTC](https://forums.swift.org/t/se-0329-clock-instant-date-and-duration/53309/7 "2021-11-05T14:19:40Z")

</div>

> [@davedelong](#):
>
> The presence of `.minutes(...)` and `.hours(...)` on `Duration` are going to be abused by developers wanting fundamentally different concepts. I do not think they should be there, because they look like the right thing, but might not actually be what you want. You think "ah, I want to show something to the user 3 hours from now, therefore I do `myWallClock.now + .hours(3)` , without realizing that this is usually the wrong approach to be taking.
> 
> Because of this, I would like to see `Duration` limited to only `.seconds(...)` .

Can you clarify why `.hours` and `.minutes` are problematic, but `.seconds` are not? If I understand correctly (and I'm very much _not_ sure that I do…), the problem is that 3 hours on a wall clock may not actually correspond to three actual hours of elapsed real-world time due to things like DST jumps? But if that's the problem, I don't see how removing `.hours` and `.minutes` makes things any better; users will just do `myWallClock.now + .seconds(3 * 60 * 60)` instead. If offsetting `wallClock.now` by a fixed amount is wrong, it's just as wrong with seconds as with minutes or hours.

I think maybe I'm just not understanding what users _should_ be using in this case?

---

<div class="post-metadata">

**Author:** ![Jumhyn](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jumhyn/32/3891_2.png) [@Jumhyn](https://forums.swift.org/u/Jumhyn)\
**Post date:** [November 5, 2021, 2:29pm UTC](https://forums.swift.org/t/se-0329-clock-instant-date-and-duration/53309/8 "2021-11-05T14:29:35Z")

</div>

My opinion, and why I advocated for their removal in the pitch thread, is that we should _want_ users to do `.seconds(3 * 60 * 60)`, since that makes it clear that they want a duration of exactly 10,800 seconds, rather than "3 hours" which is ambiguous in the face of things such as DST jumps. Performing the multiplication explicitly in source is much clearer about intent and behavior. I suppose we could also rename `.minutes` and `.hours` to something like `.standardMinutes` and `.standardHours` to give a little nudge that these may not correspond to every intuitive meaning of "hours," but I think it's better just to have users write out the multiplication explicitly.

ETA: we could also have some convenience constants like `.secondsPerMinute` and `.minutesPerHour` that give a bit more meaning to the multiplication while still giving an indication that the calculation is not calendar-aware.

---

<div class="post-metadata">

**Author:** ![davedelong](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/davedelong/32/38708_2.png) [@davedelong](https://forums.swift.org/u/davedelong)\
**Post date:** [November 5, 2021, 2:29pm UTC](https://forums.swift.org/t/se-0329-clock-instant-date-and-duration/53309/9 "2021-11-05T14:29:53Z")

</div>

The main reason is that you cannot avoid seconds when talking about temporal durations, because seconds are the fundamental unit of all physical time measurement.

Yes, people can do multiplication of factors to get longer units, but I believe it's worthwhile to discourage that by omitting the convenience methods to do so. This also speaks to the larger problem that `.hours(3)` means different things depending on which clock you're using, suggesting strongly that `Duration` should be a `Clock` associated type.

ETA: For situations like these in my own code, I go so far as to add these methods, but then mark them as unavailable so I can explain why they're the wrong thing to use:

```swift
extension Duration {
    @available(*, unavailable, message: "Use clock-specific APIs for creating durations that are measured in units longer than seconds")
    static func minutes(_ duration: Double) -> Self { ... }
    // etc
}

```

This is _also_ why my Time library explicitly names this type as the `SISecond`.

If you'd like to discuss this more, I think that'd be better served for the pitch thread, so we can keep this one focused on reviews.

---

<div class="post-metadata">

**Author:** ![Karl](https://avatars.discourse-cdn.com/v4/letter/k/34f0e0/32.png) [@Karl](https://forums.swift.org/u/Karl)\
**Post date:** [November 5, 2021, 9:06pm UTC](https://forums.swift.org/t/se-0329-clock-instant-date-and-duration/53309/10 "2021-11-05T21:06:45Z")

</div>

-1. I agree that it seems rushed.

1. I still don't like the name `InstantProtocol`. It is a value, and you can advance it by a `Duration` and find the `Duration` between two values. It is our model of a point in time, or "moment" (as others have also pointed out).

2. The `Date` API is very barebones:

3. 

> Readers may have noticed that `Date` remains `Codable` at the standard library layer but gains a new storage mechanism. The coding format will remain the same. Since that represents a serialization mechanism that is written to disk and is therefore permanent for document formats. We do not intend for `Date` to break existing document formats and all current serialization will both emit and decode as it would for double values relative to Jan 1 2001 UTC as well as the `DateEncodingStrategy` for JSONSerialization. This does mean that when encoding and decoding `Date` values it may loose small portions of precision, however this is acceptable losses since any format stored as such inherently takes some amount of time to either transmit or write to disk; any sub-second (near nanosecond) precision that may be lost will be vastly out weighed from the write and read times.

I think this needs to be explained some more. When I read the words, it seems to be saying "encoding and decoding a `Date` may return a different `Date`", which is alarming, but then it has this bit at the end about how many nanoseconds it takes to write a file to disk? What is this even talking about?

4. 

> In addition to the per clock definitions of measuring a base measurement function using the monotonic clock will also be added.

We tend to refer to these as "global functions". I think it could be made clearer that this proposal includes a new global `measure` function.

5. I still don't like the name "wall clock". My computer doesn't have walls, and no wall clock I've ever seen behaves like `WallClock`. It also looks totally weird at the call-site:

Also, I echo the concerns from above about the naming of `Date`. The Swift community clearly doesn't want or like a time API which uses `Date` to mean a non-calendrical instant in time. It's one thing to _hear_ concerns, but it's another to _listen_ to them. The Time API should be designed as though it were being made _for Swift_, to support existing and new technologies - both within Foundation's scope, and beyond it.

I wonder if a preview package might be a good idea? Clearly there are lots of people interested in the API, and it might be nice to test-drive it in order to gather better feedback.

---

<div class="post-metadata">

**Author:** ![Philippe\_Hausler](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/philippe_hausler/32/22569_2.png) [@Philippe\_Hausler](https://forums.swift.org/u/Philippe_Hausler)\
**Post date:** [November 6, 2021, 12:53am UTC](https://forums.swift.org/t/se-0329-clock-instant-date-and-duration/53309/11 "2021-11-06T00:53:44Z")

</div>

Date is required to be both Sendable and Comparable by the adherence to InstantProtocol.

---

<div class="post-metadata">

**Author:** ![Tino](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/tino/32/1073_2.png) [@Tino](https://forums.swift.org/u/Tino)\
**Post date:** [November 6, 2021, 12:15pm UTC](https://forums.swift.org/t/se-0329-clock-instant-date-and-duration/53309/12 "2021-11-06T12:15:24Z")

</div>

> [@Karl](#):
>
> I still don't like the name "wall clock". My computer doesn't have walls, and no wall clock I've ever seen behaves like `WallClock` . It also looks totally weird at the call-site:
> 
> ```swift
> DispatchQueue.main.asyncAfter(deadline: .now.advanced(by: .seconds(3), clock: .wall)
> 
> ```
> 
> I continue to prefer "system clock" and `clock: .system` .

I agree with the first part (and am somewhat puzzled that there has been no reaction to the [link](https://en.wikipedia.org/wiki/Elapsed_real_time) given… is Wikipedia considered to be wrong? Or irrelevant for Swift?), but although I think "system clock" is slightly better, it has a flaw as well:  
System time is often identified as the time as it is displayed to a user of that system — so it would return different values depending on the time zone the user has configured.  
`Date.now` on the other hand should return the same value, no matter if you are in Austria or Australia. Therefore, I'd prefer something like `UTCClock`, `CoordinatedClock`, `UniversalClock` or `WorldClock`.

---

<div class="post-metadata">

**Author:** ![gwendal.roue](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/gwendal.roue/32/13992_2.png) [@gwendal.roue](https://forums.swift.org/u/gwendal.roue)\
**Post date:** [November 6, 2021, 12:37pm UTC](https://forums.swift.org/t/se-0329-clock-instant-date-and-duration/53309/13 "2021-11-06T12:37:58Z")

</div>

> [@Karl](#):
>
> I still don't like the name "wall clock". My computer doesn't have walls, and no wall clock I've ever seen behaves like `WallClock` .

If "wall clock" is a term of art, and this proposal uses "wall clock" with a meaning that matches the expectations of a knowledgeable reader, then I'm fine with "wall clock". I see little value in being imaginative here. Reusing terms that have a different meaning in the litterature (I'm not saying you are doing this) would be even worse. This topic is already awfully complicated: there's no need to add our grain of salt

If the proposal suggest "wall clock" for what is commonly called, in computer science, a "wall clock", then we do not need to bikeshed it.

---

<div class="post-metadata">

**Author:** ![jayton](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jayton/32/5592_2.png) [@jayton](https://forums.swift.org/u/jayton)\
**Post date:** [November 6, 2021, 1:46pm UTC](https://forums.swift.org/t/se-0329-clock-instant-date-and-duration/53309/14 "2021-11-06T13:46:56Z")

</div>

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 `MonotonicClock` and `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 `ContinuousMonotonicClock` and `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 `Swift` module.

* * *

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.

* * *

How is `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.

---

<div class="post-metadata">

**Author:** ![Dante-Broggi](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/dante-broggi/32/7955_2.png) [@Dante-Broggi](https://forums.swift.org/u/Dante-Broggi)\
**Post date:** [November 6, 2021, 3:49pm UTC](https://forums.swift.org/t/se-0329-clock-instant-date-and-duration/53309/15 "2021-11-06T15:49:09Z")

</div>

I agree with most of the concerns raised above, but on another matter:

I thought of other clocks which, if added, would be best added via the stdlib: `ProcessClock`, `TaskClock` and possibly `ThreadClock`. These would be (mathematically) monotonic clocks which only and regularly tick while, respectfully, the current (or a particular other?) process, task or thread is running.

A possible use for these would be benchmarking: if a user stops and then resumes the test runner in the middle of a benchmark, I would consider it reasonable for the time while stopped to not be included in the benchmark's running time, which none of the currently proposed clocks would permit.

---

<div class="post-metadata">

**Author:** ![mayoff](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/mayoff/32/613_2.png) [@mayoff](https://forums.swift.org/u/mayoff)\
**Post date:** [November 6, 2021, 8:45pm UTC](https://forums.swift.org/t/se-0329-clock-instant-date-and-duration/53309/16 "2021-11-06T20:45:31Z")

</div>

My general sense is encoding a value-type value and then decoding the external representation should be equality-preserving, because it makes it easier to reason about the program. For example, maybe I have a big, deeply nested structure that conforms to `Equatable` and `Codable`. I can test its round-tripability using plain old `XCTAssertEqual`. Then I add a `Date` property at some deeply-nested path in the structure. Suddenly my test starts failing, and I have to jump through hoops to fix it.

(Yes, NaNs destroy equality. But under this proposal, `Date` is not a floating-point type. We shouldn't be adding more special cases that make it harder to understand how our programs behave.)

If `Date` is entering the standard library anyway, perhaps we could teach the codable containers about it. For example, add an `encode(_ value: Date)` requirement to `SingleValueEncodingContainer` with a default implementation that, for backward compatibility, uses the lossy `Double` encoding.

Under this design, it becomes possible to extend some codecs to support lossless round trips in a backward-compatible way.

In particular, JSON doesn't limit the number of digits before or after the decimal point. So `JSONEncoder` and `JSONDecoder` can be taught (with some work on the underlying `NSJSONSerialization`) to encode and decode `Date`s as numbers with perfect accuracy, while maintaining compatibility with older implementations (and with non-Swift JSON codecs).

`NSDate` is already first-class in property lists, so perhaps the property list codecs could also be enhanced to preserve equality.

---

<div class="post-metadata">

**Author:** ![Paulo\_Faria](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/paulo_faria/32/20351_2.png) [@Paulo\_Faria](https://forums.swift.org/u/Paulo_Faria)\
**Post date:** [November 6, 2021, 9:54pm UTC](https://forums.swift.org/t/se-0329-clock-instant-date-and-duration/53309/17 "2021-11-06T21:54:12Z")

</div>

**-1** I'm also not in favor of this proposal due to `Date` naming. As an API designer, I take as a guideline to always design for the future at the mercy of current users. If one does not believe that the number of future users will overtake the number of current users, then why the effort? By the same token, as a current Swift user, I'm more than happy to carry the burden so others don't have to in the future.

---

<div class="post-metadata">

**Author:** ![kiel](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/kiel/32/1392_2.png) [@kiel](https://forums.swift.org/u/kiel)\
**Post date:** [November 6, 2021, 10:40pm UTC](https://forums.swift.org/t/se-0329-clock-instant-date-and-duration/53309/18 "2021-11-06T22:40:17Z")

</div>

I have a lot of sympathy for feedback already given.

The proposal speaks to impacts on existing concurrency APIs. It seems I can pass a clock and deadline so my tests don’t wait for the deadline literally. If I understand this right, this is a great addition.

However, how will we model these types so we can pass different time passage behaviour into it to test them? Will we have to write and use yet another type erased wrapper `AnyClock` everywhere? Were alternatives to a clock protocol considered?

I wonder how this proposal might impact future concurrency APIs, too. For example, debounce, throttle and delay streams. Presumably these obviously missing APIs will quickly follow through and take clocks, durations, deadlines etc in such a way that developers can control the passage of time and test their async streams?

---

<div class="post-metadata">

**Author:** ![jrose](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jrose/32/408_2.png) [@jrose](https://forums.swift.org/u/jrose)\
**Post date:** [November 8, 2021, 4:56am UTC](https://forums.swift.org/t/se-0329-clock-instant-date-and-duration/53309/20 "2021-11-08T04:56:04Z")

</div>

I appreciate the thought the authors have put into this proposal, and I appreciate the critiques that have already shown up in this thread. I enjoy using the strongly-typed Instant/Duration model very much in Rust (and Dispatch), and I can look forward to its eventual inclusion in Swift.

I’ll put in one comment I haven’t seen here: several people have commented about Duration.nanoseconds having more precision than needed, but even if it’s reduced to Int32, are there constraints on its representation? For example, will `nanoseconds` ever have a different sign from `seconds`? Will it ever exceed 1 billion? These are general questions about normalization, but it’s important for anyone trying to access the fields.

---

<div class="post-metadata">

**Author:** ![tera](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/tera/32/38201_2.png) [@tera](https://forums.swift.org/u/tera)\
**Post date:** [November 8, 2021, 1:27pm UTC](https://forums.swift.org/t/se-0329-clock-instant-date-and-duration/53309/21 "2021-11-08T13:27:19Z")

</div>

> [@jrose](#):
>
> For example, will `nanoseconds` ever have a different sign from `seconds` ? Will it ever exceed 1 billion?

Would it be a problem to use full width of the field as an unsigned fraction? So instead of counting 10^-9 seconds it would count 2^-32 seconds and there'd be no need for constraints or normalisation. Nanoseconds would be easily obtainable from this fractional unit.

[Next page](https://forums.swift.org/t/se-0329-clock-instant-date-and-duration/53309.md?page=2)