Cookie expiration time could take Temporal.Instant or Temporal.ZonedDateTime in addition to DOMHighResTimeStamp

[ptomato]

As Temporal nears completion and is now shipping in Firefox Nightly, you could consider accepting cookie expiration times as Temporal.Instant or Temporal.ZonedDateTime objects.

Instead of this:

cookieStore.set({
    name: 'foo',
    value: 'bar',
    expires: Temporal.Now.instant().add({hours: 24}).epochMilliseconds,
});

...we could have this:

cookieStore.set({
    name: 'foo',
    value: 'bar',
    expires: Temporal.Now.instant().add({hours: 24}),
});

The latter seems preferable because the programmer doesn't have to remember that a DOMHighResTimeStamp is in milliseconds.

[annevk]

I wonder if this can be an IDL feature, whereby the specification (or implementation) still ends up with a number (a DOMHighResTimeStamp). E.g., [CoerceTemporalToDOMHighResTimeStampEpoch].

[domenic]

Maybe it should just always work, for all DOMHighResTimeStamp instances?

We'd probably have to make DOMHighResTimeStamp a proper type in IDL instead of a typedef. But, still seems nice.

[annevk]

I don't think it can work for all of them since not all of them are for epoch times. But maybe we should make separate types for epoch and relative and let it all flow from there.

cc @yoavweiss

[yoavweiss]

Makes general sense to me!

So timeOrigin would be the new epoch-based type, and other measurements that are relative to it will remain DOMHighResTimeStamp? Would one be able to convert a Temporal.instant to both?

^^ @noamr @jyasskin

[jyasskin]

Doing this as WebIDL types makes a lot of sense to me, at which point this issue isn't in the right repository. We'll need 4 types: {Instant, Duration} x {allow numbers (legacy), disallow numbers}. I think we can avoid the clock distinctions, but we can discuss that in the WebIDL issue.

[domenic]

When would we not want to allow numbers? Numbers seem good to allow. I think we only want two types.

[noamr]

When would we not want to allow numbers? Numbers seem good to allow. I think we only want two types.

Arguably, it's very easy to pass epoch-based timestamps to functions/properties that accept monotonic timestamps, resulting in nonsensical outcomes. Not sure this means we should disallow number-based timestamps in future APIs, but it's at the very least a legit thing to consider.

[noamr]

I don't think it can work for all of them since not all of them are for epoch times. But maybe we should make separate types for epoch and relative and let it all flow from there.

cc @yoavweiss

How do we envision this working for relative/monotonic timestamps? It would assume that the global object's timeOrigin is the relevant one here?

[jyasskin]

Numbers are easily confused between instants and durations. Sometimes you can name the method or field to be clear which it expects, but, for example, setTimeout() isn't named that way. Not everyone even measures time in milliseconds. There's a consistency argument in w3ctag/design-principles#425 that we should accept the resulting bugs, but I'd rather that future APIs restrict themselves to more precise types instead.

Temporal doesn't have a type to represent "timestamps" on the monotonic clock, so those have to be Durations (generally from the time origin, but performance.timeOrigin, which expresses that instant to JS, is itself a duration). I think most of these are returned from methods rather than passed to them, and we can't change existing return types without breaking backward compatibility.