For how calendar durations are added, see Temporal.PlainDate.prototype.add()
.
Addition and subtraction are performed according to rules defined in RFC 5545 (iCalendar):
- Add/subtract the date portion of a duration using calendar arithmetic; in other words, add the date portion to its
PlainDateTime
using Temporal.PlainDateTime.prototype.add()
, and then interpret the result in the same time zone. The result will automatically adjust for daylight saving time using the rules of this instance's timeZone
field. For example, 2024-11-03T01:00:00-04:00[America/New_York]
plus one day is 2024-11-04T01:00:00-05:00[America/New_York]
, as if the day has 25 hours. - If the date-time is ambiguous or invalid due to a time zone offset transition, it is resolved using the
disambiguation: "compatible"
behavior: the later of the two possible instants will be used for time-skipped transitions and the earlier of the two possible instants will be used for time-repeated transitions. For example, 2024-03-09T02:05:00-05:00[America/New_York]
plus one day is supposedly 2024-03-10T02:05:00-05:00[America/New_York]
, but this time doesn't exist, so the wall-clock time one hour after, 2024-03-10T03:05:00-04:00[America/New_York]
, is returned. - If the offset is ambiguous, it is resolved using the
offset: "prefer"
behavior: the offset is used if it's valid for the time zone and the local time, and recalculated otherwise. For example, 2024-11-02T01:00:00-04:00[America/New_York]
plus one day is 2024-11-03T01:00:00-04:00[America/New_York]
, while 2024-11-04T01:00:00-05:00[America/New_York]
minus one day is 2024-11-03T01:00:00-05:00[America/New_York]
. - If the resulting date-time's components are out of bounds, they are resolved using the
overflow
option. For example, 2024-08-31
plus one month is 2024-09-31
which doesn't exist, so it is clamped to 2024-09-30
by default.
- Add/subtract the time portion of a duration using real-world time; in other words, add the time portion to its
Instant
using Temporal.Instant.prototype.add()
, and then interpret the result in the same time zone. For example, 2024-11-03T01:00:00-04:00[America/New_York]
plus one hour is 2024-11-03T01:00:00-05:00[America/New_York]
.
These rules make arithmetic with Temporal.ZonedDateTime
"DST-safe", which means that the results most closely match the expectations of both real-world users and implementers of other standards-compliant calendar applications. These expectations include:
- Adding or subtracting days should keep clock time consistent across DST transitions. For example, if you have an appointment on Saturday at 1:00PM and you ask to reschedule it 1 day later, you would expect the reschedule appointment to still be at 1:00PM, even if there was a DST transition overnight.
- Adding or subtracting the time portion of a duration should ignore DST transitions. For example, a friend you've asked to meet in in 2 hours will be annoyed if you show up 1 hour or 3 hours later. There should be a consistent and relatively-unsurprising order of operations.
- If results are at or near a DST transition, ambiguities should be handled automatically (no crashing) and deterministically.
Adding a duration is equivalent to subtracting its negation.