Why adding a month to a date is ambiguous

Days are all the same length. Months are not, and that single fact makes calendar arithmetic one of the most quietly broken things in everyday computing.

The 31 January problem

What is one month after 31 January? There is no 31 February, so an answer has to be invented. The most common convention clamps to the last valid day of the target month, giving 28 February — or 29 in a leap year. Some systems instead overflow into the next month, giving 3 March. Both are defensible and they disagree by three days.

This is not an edge case that never arises. Monthly billing, subscription renewals, notice periods and payment terms all hit it every year, and a system that clamps talking to a system that overflows will drift apart on exactly the dates that matter most to someone.

Month addition does not reverse

Under the clamping convention, adding one month to 31 January gives 28 February. Subtracting one month from 28 February gives 28 January. You have not returned to where you started, and no amount of care in the implementation fixes it — the operation simply is not invertible.

The order of operations matters too. Adding one month twice is not always the same as adding two months at once, because each step clamps independently and information about the original day is lost at the first step. Anywhere a contract says three monthly extensions, it is worth knowing which route the system takes.

Days are safe, months are not

Counting in days avoids all of this, because days are uniform. The gap between two dates in days is unambiguous, reversible and identical in every implementation. This is why financial and legal instruments so often specify day counts rather than months, and why a due date calculated as plus 280 days is more robust than plus nine months.

The cost is readability. Ninety days and three months feel equivalent to a person but differ by up to two days depending on which months are involved, and by more across a year boundary. When a document is ambiguous, the day count is the interpretation less likely to be disputed.

Leap years and the rules people forget

A year is a leap year if it is divisible by four, except centuries, except centuries divisible by four hundred. So 1900 was not a leap year and 2000 was. The rule catches out a surprising amount of software, and the exceptions arrive rarely enough that the bug lies dormant for a century.

The practical consequence is smaller but constant: any span crossing 29 February is one day longer than the same span in an ordinary year, and converting a day count back into years yields a fraction rather than a round number. An annual period of 365 days is not a year in three out of four years.

Inclusive or exclusive?

How many days from Monday to Friday? Four if you measure the gap between them, five if you count the days themselves. Both are correct English and they differ by one, which is enough to miss a deadline.

Legal and contractual periods usually specify. Notice periods often exclude the day of service and include the last day; delivery estimates often count business days starting the day after dispatch. Where nothing is specified, the inclusive count is the safer assumption for anything you must not be late for, and stating your interpretation in writing is safer still.

Time zones make it worse

A date is not a moment. Midnight on the first of the month happens at different instants around the world, so a deadline expressed as a date is ambiguous across zones by up to a day either side. Daylight saving adds two days a year that are twenty-three or twenty-five hours long, which breaks any calculation assuming a day is always 86,400 seconds.

For anything that matters, state the zone. A deadline of 1 September is an invitation to a dispute; 23:59 on 31 August, London time, is not.