Interval types: exact vs calendar

[redneb]

(apologies if this has been discussed already, I couldn't find a relevant issue)

I looked into this proposal today and really like the taxonomy of types that it introduces with one exception, the Duration type.

While it seems that care has been taken to separate timestamp types into exact types (i.e. Instant) and calendar types (e.g. PlainDateTime or PlainDate), the same cannot be said for interval types where there is only one type, Duration, that functions sometimes as an exact type and sometimes as a calendar type. I would have expected that there are 2 interval types, let's call them Interval (an exact type) and Period (a calendar type).

A Period would basically be like Duration in the current proposal: it would denote a number of years plus a number of months plus a number of days plus a number of hours, etc. An Interval on the other hand would denote an exact number of nanoseconds and could be stored as a single bigint. It should still be possible to create an Interval from milliseconds/seconds/minutes/hours/days/weeks (but not from months/years). But unlike Period, one day in an Interval will always be exactly 86400 seconds and we don't care about calendar issues such as periods that include a change from DST to standard time.

In other words, an Interval (which is an exact type) is the difference between two Instants (also an exact type) and a Period (which is a calendar type) is the difference between two calendar types such as PlainDateTimes or PlainDates. So schematically, we should have something like this:

Instant - Instant = Interval
PlainDateTime - PlainDateTime = Period

and

Instant + Interval = Instant
PlainDateTime + Period = PlainDateTime

All other combinations (i.e. mixing exact and calendar types) should not be allowed. So for example this would eliminate issues that arise with the current proposal such as

Temporal.Instant.from("2021-02-12T02:20:00Z").add(Temporal.Duration.from({days: 1}));

which throws an exception. I think it is preferable to avoid partial functions (such as add in the above example) and use better types that can model the problem more accurately.

[ptomato]

Thanks for writing this up!

We did consider alternate schemes such as having two different types, or having a calendar Duration and using a bigint number of nanoseconds for exact arithmetic. In the end we landed on the current solution: Duration matches the semantics described in RFC 5545 because it's an existing standard that in most cases seems to coincide with what programmers intuitively expect. While this proposal leans heavily on strong typing, having two separate types for durations seemed to place a high cognitive burden on developers unfamiliar with the distinction.

Here are some links to previous discussions on this topic:

• Interaction of Duration vs DST (or other TZ offset changes) #559
• Options for handling "3 kinds of durations" problem #686
• Proposed Temporal changes required to adopt RFC 5545 (iCalendar) meaning of durations #759
• https://github.com/tc39/proposal-temporal/blob/main/meetings/agenda-minutes-2020-09-10.md
• https://github.com/tc39/proposal-temporal/blob/main/meetings/agenda-minutes-2020-07-16.md
• https://github.com/tc39/proposal-temporal/blob/main/meetings/agenda-minutes-2020-07-09.md