Adding a month to a date, and why the answer varies

By Niraj Kumar · Published October 28, 2026

Add one month to 15 March and nobody disagrees: 15 April. Add one month to 31 January and the trouble begins, because there is no 31 February. Every library, database and spreadsheet has an answer, and they do not all agree. The date calculator on this site gives 28 February, or 29 in a leap year, and says why; this guide is about the alternatives and the consequences for anything that recurs monthly.

Clamp or overflow

There are two common behaviours. Clamping keeps the result in the target month by moving to its last day: 31 January plus a month is 28 February. Overflow adds the missing days on to the next month: 31 January plus a month is 31 February, which does not exist, so it becomes 3 March in a common year or 2 March in a leap year. Clamping is what people usually mean and what most modern date libraries do: Java’s plusMonths, Python’s dateutil.relativedelta, PostgreSQL’s interval arithmetic and Excel’s EDATE all clamp. JavaScript’s original Date overflows: setMonth on 31 January produces 3 March. C’s mktime normalises the same way. A system built on either of those has to clamp explicitly.

It does not add up

Once a result can be clamped, month arithmetic stops being associative. 31 January plus one month is 28 February; plus another month is 28 March. But 31 January plus two months, done in one step, is 31 March. The order and grouping of operations change the answer by three days. A system that advances a date one month at a time drifts to the 28th and stays there forever; one that computes each date from the original anchor keeps the 31st whenever the month has one. The second is nearly always what was intended, and it is why the rule should be “months from the anchor date”, never “a month from the last date”.

Days versus months

Mixing units makes it worse. One month and one day from 30 January: add the month first and clamp to 28 February, then the day, giving 1 March. Add the day first, giving 31 January, then the month, clamped to 28 February. Different results from the same input. ISO 8601 durations such as P1M1D deliberately leave the order to the application, and the convention most libraries use is largest unit first: years, then months, then days. State it, because someone else’s tool will assume the other.

A month is not thirty days

A tempting shortcut is to define a month as 30 days, or 30.44, and add seconds. Doing that from 15 March gives 14 April, which no one calling it a month expects, and over a year it drifts by five days. Durations in seconds are right for elapsed time and wrong for calendar periods, and the two should be different types in any code that handles both. The time duration tool works in elapsed units; the date calculator works in calendar units; they answer different questions and will disagree by design.

Billing, renewals and payroll

A subscription taken out on 31 January has to be charged in February, and the business has to decide when. The usual answer is the last day of the month whenever the anchor day does not exist, then back to the anchor day when it does: 31 January, 28 February, 31 March, 30 April, 31 May. That is the clamp-from-anchor rule. Some systems instead move every subsequent charge to the 28th, which quietly shortens the billing cycle; others charge on the 1st of the following month for any anchor beyond the 28th. All are workable; none is self-evident, and the terms should say which. The same applies to rent, loan instalments, monthly notice periods and the expiry of a contract measured in months. A notice period of one month given on 31 January ends on 28 February under the clamp rule and on 3 March under overflow, and the difference has been argued in court.

Years, and 29 February

Adding a year is adding twelve months and has the same issue once a year in four. 29 February 2024 plus a year clamps to 28 February 2025. Plus four years it is 29 February 2028 again, provided the calculation is anchored to the original rather than stepped a year at a time. The leap year guide covers the days themselves, and the age guide the related question of birthdays.

Subtracting, and going backwards

Subtraction has the same rules in reverse. 31 March minus a month is 28 February under clamping, and the asymmetry matters: 28 February plus a month is 28 March, not 31 March, so adding and then subtracting a month does not return to the start. Any calculation that needs to be reversible has to keep the anchor date rather than the intermediate result.

What to do

Pick clamping unless a rule says otherwise. Compute every recurring date from the original anchor, not from the previous occurrence. Apply years, then months, then days, and say so. Keep calendar durations and elapsed durations as different kinds of value. And test with 31 January, 29 February and 31 October, because a routine that gets those three right gets everything right. The date calculator and the date difference tool follow these rules, and both state the clamping when it has happened rather than leaving the reader to notice that the day of the month changed.