Date Calculator

Adding a month is the one step in this calculator that cannot always land where it is told. Months run from 28 to 31 days, so a start date on the 29th, 30th or 31st sometimes has nowhere to go: February has no 31st, and most years have no February 29 either. The convention — used by legal calendar-month counting, most spreadsheet libraries and this tool — is to clamp downward to the target month's final day. The overflow days are dropped rather than carried forward, which keeps the result inside the month you asked for.

The clamp pair below is the case worth memorising. January 31, 2024 plus one month reaches February 29, 2024, because that February holds 29 days; the identical move a year earlier stops at February 28, 2023. Same start day, same offset, different result — entirely because the leap year changed the target month's length. Subtracting clamps by the same rule: March 31, 2024 minus one month is February 29, 2024, not March 1.

Weeks and days behave differently, and deliberately so. A week is always seven days and a day step is always one day, so neither ever clamps: January 31, 2024 plus one day is February 1, 2024, cleanly past the month boundary. Only the year and month steps compress, because only they name a target month that may be too short.

One consequence follows from all this: an offset that crosses a clamp does not always round-trip. January 31, 2024, moved forward a month and back a month, finishes on January 29 — the forward step lost two days to the clamp, and the return journey has no memory of them. That asymmetry is a property of the calendar, not a bug in the arithmetic, and it is the reason the fixed application order below matters.

An offset with several non-zero fields needs a rule for which moves first, and this calculator applies them in the order years, months, weeks, days. Years go first so a February 29 anniversary is settled before any month step can move it again. Months come next, clamping as needed. Weeks and days finish the job as plain day arithmetic, which is exact at every step.

The order is invisible whenever no clamp occurs — one month and two days from October 9, 2026 reaches November 11 whichever way you sequence it. It surfaces the moment the two steps disagree at the finish, as this pair shows. Both rows subtract the same two amounts from the same start date; only the sequence differs.

The gap appears because both routes pass through the same midpoint, September 9, and then finish with different steps from there. Thirty exact days back from September 9 is August 10; a calendar month back from September 9 is August 9, because that particular August-to-September month holds 31 days, one more than the 30 the day step counts. The practical takeaway is simpler than the mechanics: this tool always applies months before days, which is the order most calendar libraries and manual date arithmetic use, so an offset written as one month plus 30 days here means exactly what it means on paper.

The Before toggle interacts with the order in a way worth stating once. Subtracting does not reverse the sequence — it negates every field and applies them in the same years, months, weeks, days order. One month and 30 days before October 9, 2026 therefore means one month back first (September 9) and then 30 days back (August 10), which is the reading the worked example above shows.

Date arithmetic has two classic failure modes, and both are avoided by staying in UTC end to end. The first is the daylight-saving hour: in zones that observe DST, a local day in March or November can hold 23 or 25 hours, and naive millisecond arithmetic lands an hour off, occasionally tipping a date onto the wrong calendar day. Working at midnight UTC with whole-day steps makes that impossible — a day is 86,400,000 milliseconds everywhere, every day of the year.

The second is the time zone itself. Because every parse and every weekday lookup reads UTC fields, a given start date and offset produce the same answer on every device on Earth. There is no quietly-taken local midnight to disagree about, and no server involved either — the calculation runs in the browser, on whatever date you typed.

Output is deliberately single-format. The primary result is an ISO 8601 date — 2026-11-08 — the one written form that is unambiguous internationally, sorts correctly as text, and pastes cleanly into spreadsheets, code and log files. The long form beside it, Sunday, 8 November 2026, exists for human reading and for double-checking that the weekday matches your expectations; both are derived from the same UTC date, so they can never disagree.

• 30 days after October 9, 2026 is 2026-11-08, a Sunday — a plain day step, no clamping involved.
• Two weeks after October 9, 2026 is 2026-10-23, a Friday — 14 exact days, landing on the same weekday.
• One month after January 31, 2024 is 2024-02-29; one month after January 31, 2023 is 2023-02-28 — the clamp pair.
• One month and 30 days before October 9, 2026 is 2026-08-10, a Monday — months applied before days, as everywhere in this tool.