Summary of discussions from tc39/proposal-temporal#205 and tc39/proposal-temporal#682.
From user feedback, it seems that the main use cases are iterating through a range between two points on the time line (whether exact time or calendar/wall-clock time), and having an interval object which boxes up two orderable Temporal objects with methods for checking whether another Temporal object or interval lies within the range.
Possible APIs proposed:
const start = new Temporal.PlainDate(2021, 1, 1);
const end = new Temporal.PlainDate(2020, 12, 31);
const step = Temporal.Duration.from({ days: 1 });
for (const date of Temporal.range(start, end, step)) { ... }
class Interval {
constructor(startInstant, endInstant) { ... }
static from(isoStringOrIntervalLike) { ... }
contains(instant) { ... }
intersects(interval) { ... }
encloses(interval) { ... }
equals(interval) { ... }
*iterate(duration) { ... }
get start() { ... }
get end() { ... }
get duration() { ... }
with(intervalLike) { ... }
toString(startTimeZone, endTimeZone) { ... }
...
}
Advantages:
Intervals are not difficult to implement in userland, but it could be a benefit for Temporal to have a type with a consistent set of operations, and to avoid off-by-one errors.
Concerns:
An Interval object doesn't quite fit with the strict typing philosophy of Temporal. It's possible there would have to be different Interval types for the different Temporal types: at least Instant and ZonedDateTime, probably PlainDateTime and PlainDate, and possibly PlainYearMonth and PlainTime. Probably business logic would use at most one of these types at a time.
Prior art:
Constraints / corner cases:
- Is it correct to have an interval with non-exact types, since iterating through it might mean that the steps aren't always equal in exact time?
- ISO 8601 interval strings (at least before the 2019 edition) don't take negative durations into account, but Temporal allows negative durations.
Summary of discussions from tc39/proposal-temporal#205 and tc39/proposal-temporal#682.
From user feedback, it seems that the main use cases are iterating through a range between two points on the time line (whether exact time or calendar/wall-clock time), and having an interval object which boxes up two orderable Temporal objects with methods for checking whether another Temporal object or interval lies within the range.
Possible APIs proposed:
Advantages:
Intervals are not difficult to implement in userland, but it could be a benefit for Temporal to have a type with a consistent set of operations, and to avoid off-by-one errors.
Concerns:
An Interval object doesn't quite fit with the strict typing philosophy of Temporal. It's possible there would have to be different Interval types for the different Temporal types: at least Instant and ZonedDateTime, probably PlainDateTime and PlainDate, and possibly PlainYearMonth and PlainTime. Probably business logic would use at most one of these types at a time.
Prior art:
IntervalDatePeriodConstraints / corner cases: