What "one month later" actually means (dates are harder than they look)

What date is one month after 31 January? Take a moment — because every candidate answer has a problem. 28 February skips three days’ worth of “length”. 3 March (31 days later) is not “the same day next month”. And “31 February” does not exist. Any answer requires a decision, not just arithmetic, and different systems decide differently.

Days are easy; months are not

Adding days to a date has one right answer: 30 days after 31 January is 2 March, full stop. Days are all the same length, so the arithmetic is mechanical.

Months are not the same length — 28, 29, 30 or 31 days — so “add one month” cannot mean “add a fixed amount of time”. What people intuitively mean is “same day-of-month, next month”, and that intuition works for days 1–28. It breaks for the 29th, 30th and 31st whenever the target month is shorter than the source month.

The two standard answers

Clamping (also called snapping): if the target day does not exist, use the last day of the target month. One month after 31 January is 28 February (29 in a leap year). This is what most calendar apps, spreadsheet functions and date libraries do, and it matches how humans schedule: “the rent is due on the 31st” means the last day of the month in February, not a spillover into March.

Rolling over: keep the arithmetic literal and let the overflow spill forward — 31 January plus one month becomes 2 or 3 March. Almost nothing intends this behaviour, but plenty of software produces it by accident, because naive implementations that just increment the month number and leave the day alone create “31 February”, which the date system then “helpfully” normalises into March.

The date tools here clamp, deliberately, and say so.

Clamping is not reversible — and not associative

Two consequences of clamping catch people out.

It loses information. 28 February minus one month is 28 January — not the 31 January you may have started from. Three different start dates (29, 30, 31 January) all clamp to the same 28 February, so the reverse journey cannot know which one you meant. Any system that schedules “same day next month” repeatedly, like a subscription billed on the 31st, drifts to the 28th after the first February and stays there unless it remembers the original anchor day separately. Real billing systems store “bill on day 31” as intent, precisely so February does not permanently reset it.

Order matters. Add one month then one day to 31 January: clamp to 28 February, then 1 March. Add one day then one month: 1 February, then 1 March — the same here, but with other date combinations the two orders genuinely differ. Compound offsets (“1 month and 15 days”) are only well-defined once you fix the order of operations; conventionally months are applied first.

Where this shows up: ages and anniversaries

An age of “1 month” for a baby born 31 January is exactly this problem wearing different clothes. Measured on 1 March, is the baby one month and one day old? Whole-month counting says: born 31 January, the first month completes on 28 February (clamped), so on 1 March the age is one month and one day.

Building the age calculator on this site surfaced how easy this is to get wrong: an early implementation that borrowed days from February the naive way produced a negative day count (an age of “1 month, −2 days”) for exactly this birthday. The fix was to count whole months with clamping and then count the leftover days — and to add a test asserting the age calculation and the next-birthday calculation can never disagree with each other, since both must make the same clamping decision.

The same convention question decides when a 29 February birthday “falls” in a common year (28 February or 1 March — legally it varies by country) and when a contract signed 31 August reaches its “six-month” point (28 February, by clamping).

The takeaway

“Add a month” is a convention, not a computation. The clamping convention matches human intent nearly always, at the cost of being lossy — so the right mental model is: same day next month, or the closest that exists, and never trust it to reverse. When a date calculation near a month-end matters, check what the specific system does with the 29th, 30th and 31st; that is where every implementation reveals its choice.