Durations & intervals
Spans vs points — and why "1 month" and "30 days" are not the same thing.
An instant is a point on the timeline. A duration is a length of time — the distance between two instants. Durations come in two flavours that behave very differently.
An exact duration is measured in fixed physical units: seconds, minutes, hours. “3600 seconds” is unambiguous; it is the same length of time regardless of when it starts or what timezone is involved.
A calendar duration is expressed in human calendar units — days, months, years — and its exact length depends on when it is applied. One calendar day spans the local midnight-to-midnight window, which DST can make 23 or 25 hours long. One calendar month is 28, 29, 30, or 31 days. One calendar year is 365 or 366 days. “Add 1 month” is not the same operation as “add 30 days”.
Intervals
An interval is a concrete span of time with a definite start and end. It can be represented as (start instant, end instant), (start instant, duration), or (duration, end instant). Interval arithmetic is well-defined once both endpoints are resolved to instants.
Pitfall: Adding “1 month” to January 31 is ambiguous. February has fewer than 31 days, so the result is undefined. Different libraries resolve this differently — some clamp to the last day of the month (Feb 28/29), some throw an error. Always check and document your library’s behaviour.
Go deeper: ISO 8601 duration notation and its traps
ISO 8601 uses the notation P1Y2M3DT4H5M6S to express durations: P followed by date components (years, months, days) then T followed by time components (hours, minutes, seconds). This is supported by many libraries and databases.
However, the mixed form (P1MT30S — one month and thirty seconds) is dangerous to compute with because the month part is calendar-relative while the second part is exact. You cannot convert such a combined duration to a fixed number of seconds without knowing the start instant. Libraries that try to do so silently are a bug source.
A safe rule: keep calendar durations (years/months) separate from exact durations (days/hours/minutes/seconds) in your data model. Only mix them when adding to a specific known start instant.
For the concrete edge cases involving DST and calendar-day length, see DST & the edges.