Online Tool Store
Date Adder
Add or subtract years, months, weeks, days and hours from a date, choosing how month overflow behaves, with clock changes and working days handled.
🔒 This tool runs entirely in your browser. Your files are never uploaded to a server.
Resulting date
—
How to use it
- Set the starting date, and a time if it matters.
- Enter how much to add or subtract in any combination of units.
- Choose whether a month overflow clamps or rolls over.
- Read the result, with the day of the week and the elapsed time.
"Plus one month" is genuinely ambiguous
Adding a month to the 31st only works if the target month has one. When it does not, software has to pick a convention, and the two sensible choices disagree:
31 Jan 2026 + 1 month clamp → 2026-02-28
roll → 2026-03-03 three days apart
31 Mar 2026 + 1 month clamp → 2026-04-30
roll → 2026-05-01
Most date libraries clamp, and most say nothing about it. For a subscription renewal or a contract term that silence is a real problem — three days is a billing period boundary. Here the choice is a switch, and when it actually changes the answer the tool shows you what the other convention would have given.
Clamping breaks associativity
The consequence catches people out even when they know about clamping. Adding a month twice is not the same as adding two months:
31 Jan → +1 month → 28 Feb → +1 month → 28 Mar
31 Jan → +2 months → 31 Mar
Both follow the same rule correctly. The information about "the 31st" is destroyed by the first clamp and cannot be recovered, so stepping month by month through a schedule drifts away from calculating each date from the original start. If you are generating a year of monthly dates, always add n months to the original rather than one month to the previous result.
A day is not always 24 hours
In local time, twice a year it is not. Where summer time applies, one day loses an hour and another gains one:
Europe/London, 2026
12:00 on 28 Mar → 12:00 on 29 Mar 23 hours
12:00 on 24 Oct → 12:00 on 25 Oct 25 hours
offset moves GMT+00:00 ⇄ GMT+01:00
Adding "one day" should keep the wall-clock time, which is what this does — and the elapsed hours then genuinely are 23 or 25. Adding 24 hours instead would shift the clock time by an hour. Both are defensible depending on what you mean, and the tool flags the crossing so you know which situation you are in rather than discovering it later.
The order the units are applied
1. years and months with clamping or rolling
2. weeks and days skipping weekends if asked
3. hours and minutes exact elapsed time
Fixed rather than left to chance, because doing days before months can land somewhere else entirely when a clamp is involved. It is the order every date library uses, and stating it is the only way you can check the result against what you meant.
FAQ
What is 31 January plus one month?
There is no single right answer, which is why the tool asks. Clamping gives 28 February, because the 31st does not exist that month. Rolling the surplus over gives 3 March. Most software clamps and does not tell you, so the two conventions differ by three days without anyone noticing.
Why does adding one month twice differ from adding two months?
Because clamping loses information. From 31 January, one month lands on 28 February, and another month from there lands on 28 March. Adding two months in one step gives 31 March. Both are correct applications of the same rule; calendar arithmetic simply is not associative.
Is a day always 24 hours?
No, not in local time. Where clocks change for summer time, one day a year is 23 hours and another is 25. In Europe/London during 2026, the same wall-clock time on 28 and 29 March is 23 hours apart, and on 24 and 25 October it is 25. The tool notices when your calculation crosses one of those boundaries and says so.
What does "working days" skip?
Saturdays and Sundays, and nothing else. Public holidays are not included, because they differ by country and region and this tool has no calendar of them — assuming a set would be worse than saying so.
Why are months applied before days?
Because the order changes the answer whenever a month change involves clamping, so it has to be fixed and stated rather than left to whichever field you filled in first. Months and years go first, then weeks and days, then hours and minutes.
What about 29 February?
Adding a year to 29 February 2024 gives 28 February 2025 when clamping, since 2025 has no 29th. That is the standard behaviour, and it is the reason a leap-day anniversary is genuinely ambiguous rather than simply unhandled.
How we compare
| Feature | Online Tool Store | Other date calculators | A spreadsheet formula |
|---|---|---|---|
| Lets you choose clamp or roll-over | ✓ | Silently clamps | Depends on the function |
| Shows what the other convention would give | ✓ | ✗ | ✗ |
| Warns when the clocks change in between | ✓ | ✗ | ✗ |
| Working-days mode | ✓ | Sometimes | ✓ |
| States the order units are applied in | ✓ | ✗ | You write it |
| Public holidays | ✗ | Some, by country | If you supply a list |
| Works across a column of dates | ✗ | ✗ | ✓ |
For one date where the edge cases matter — a renewal on the 31st, a deadline across a clock change — this shows you the ambiguity instead of hiding it. It has no holiday calendar and cannot work down a column, so for a schedule of dates in a specific country a spreadsheet with your own holiday list is the better tool.