Adding one day to a stamp in a zone that shifts its clocks: which two answers can that produce, and when do they differ?

## Two arithmetics wear the same words *Plus one day* can mean either of two things, and they are not the same operation: - **Duration arithmetic** adds a fixed elapsed amount to a point on the timeline: twenty-four hours, eighty-six thousand four hundred seconds. It consults no calendar and no zone; it moves along the timeline and lands where it lands. - **Calendar arithmetic** targets a described position: the same clock time on the next calendar day, in some zone. It consults that zone's rules to work out which moment answers the description. Away from a transition the two agree exactly, which is why the distinction stays invisible for most of the year and then stops being invisible. ## What a clock shift does to the length of a day In a zone that shifts its clocks seasonally, one calendar day each year is short and one is long: | Situation | Length of the calendar day | Same clock time tomorrow | Twenty-four hours later | |---|---|---|---| | An ordinary day | 24 hours | advances 24 hours | reads the same clock time | | The day clocks go forward | 23 hours | advances 23 hours | reads one hour later than the start | | The day clocks go back | 25 hours | advances 25 hours | reads one hour earlier than the start | Concretely, starting at 09:00 on the day clocks go forward, calendar arithmetic gives 09:00 the next day, which is twenty-three hours of elapsed time, while duration arithmetic gives 10:00 the next day, which is twenty-four. On the day clocks go back the two swap places. ## Which one a given operation performs is not universal Some designs make the distinction in the type system: an elapsed amount is one type, a calendar step is another, and adding each does visibly different things. Others expose a single day-shaped helper whose behaviour is fixed by the design — in several it performs calendar arithmetic, in others it is exactly twenty-four hours — and the name alone does not tell you which. Where a column is held as an integer count of a fixed unit since an origin, plain addition can only be duration arithmetic, because there is no zone in the representation for a calendar rule to consult. So the useful form of the question is not *what does plus one day do* but *which of the two arithmetics does this operation perform, and which did I want*. ## Which one you wanted Ask what the requirement is stated in: 1. **A promise about the clock.** A statement due at 09:00 the next business day, a nightly cut-off, a reminder at the same local time. That is calendar arithmetic, performed in the relevant local zone. Implemented in elapsed hours, the local time drifts by an hour after each shift and never drifts back. 2. **A promise about elapsed time.** A token valid for twenty-four hours, a four-hour service commitment, a decay applied per hour. That is duration arithmetic, performed on instants. Implemented in calendar terms, it silently grants or removes an hour twice a year. 3. **An interval in a report.** Say which you mean before writing it, because a reader will assume the other one. ## Where it bites in data work - **A cut-off computed by adding.** Rows are kept if their stamp is below *start plus one day*. Across a shift the two arithmetics keep a different set of rows, and the difference is an hour's worth of records. - **An age or a tenure.** Elapsed time measured in calendar units and elapsed time measured in hours disagree whenever a shift falls inside the span, so two implementations of the same metric drift apart and nobody can say which is right. - **A sequence of local positions.** Anything derived by repeatedly adding one day in a shifting zone either keeps the clock reading or keeps the spacing; it cannot keep both. - **A backfill.** Re-running a range that contains a shift with the other arithmetic quietly produces a different answer than the original run, which is exactly the kind of discrepancy nobody can explain a year later. ## The habit worth having State the arithmetic in the code rather than in a comment. Where the requirement is elapsed time, compute on instants and name the amount in hours or minutes. Where the requirement is a clock reading, compute in the local zone, say so, and convert the result back to an instant immediately afterwards. And when you write a boundary into a specification, write *exactly twenty-four hours* or *the same clock time the next calendar day* — never *plus one day*, which is the phrase that let the ambiguity in.