Add Days to a Date Calculator

Background.

This calculator moves a date. Give it a starting date, choose whether to go forward or backward, pick a unit — days, business days, weeks, months or years — and it returns the date you land on, the weekday that date falls on, its ISO 8601 form, its ordinal day-of-year number, the net number of calendar days you actually moved, and how many weekend days sit inside that span. It is the inverse of a date difference calculator: that one takes two dates and tells you the gap, this one takes one date and a gap and tells you the other date.

The reason a page like this exists rather than a mental shortcut is that date arithmetic is not the arithmetic most people assume it is. Adding 90 days to a date is not adding three months, because three months can be 89, 90, 91 or 92 days depending on which three months you cross. Adding one month to the 31st of a month lands on a day that does not exist half the time. Adding a year to 29 February lands on a day that exists only once every four years. Every one of those cases has a convention attached, and this calculator states which convention it uses instead of hiding it.

The month-end convention is the one that surprises people most, so it is worth stating up front, beside the answer rather than buried. When the day-of-month does not exist in the target month, the result is clamped back to the last day of that month: 31 March plus one month is 30 April, 31 January plus one month is 28 February (29 February in a leap year), and 29 February plus one year is 28 February. That is the rule used by java.time in Java, by relativedelta in Python's dateutil, and by most database engines, and it is the closest thing to a standard that exists — ISO 8601 defines how to write dates, not how to add months to them. One consequence follows directly and catches people out: month arithmetic done this way is not reversible. Add a month to 31 August and you get 30 September; subtract a month from 30 September and you get 30 August, not the 31st you started from. The calculator tells you on the face of the result whenever clamping has been applied, so you are never quietly handed a date that has silently lost a day.

A second consequence is that the offset is applied once, from the original date, not stacked one unit at a time. Two months from 31 January is 31 March, because March has a 31st. One month from 31 January, then another month from that result, is 28 March. Both answers are defensible; they are simply answers to different questions. This calculator always answers the first one, which is what a contract that says 'two months from signature' means.

Business-day mode counts Monday to Friday and skips Saturday and Sunday. It does not know about public holidays, and there is no country in which weekends alone are a complete answer for a legal deadline. If you are counting a court filing window, a statutory notice period, a probation period or a payment term, you have to remove the holidays your jurisdiction recognises as well — and you should check first whether the rule you are working to counts calendar days rather than business days at all, because many do. The calculator says this beside the result rather than hiding it in an FAQ, because a deadline is exactly the kind of number a reader trusts before they open an accordion.

Everything is computed at UTC midnight on the proleptic Gregorian calendar. Anchoring in UTC matters because a naive local-time implementation adds or removes an hour twice a year at the daylight-saving transitions, and an off-by-one hour at midnight is an off-by-one day in the answer. The proleptic Gregorian part matters only for very old dates: the modern leap-year rule is projected backwards past 1582, which is mathematically consistent and is what essentially every piece of date software does, but it is not the calendar that was actually in civil use in, say, England in 1700.

What is add days to date calculator?

Date offset arithmetic is the operation of moving a calendar date forward or backward by a stated quantity of a stated unit. It splits cleanly into two families that behave very differently. Days and weeks are exact: a week is always seven days, so adding weeks is adding a multiple of seven days and nothing can go wrong. Months and years are not exact, because months have between 28 and 31 days and years have 365 or 366, so month and year arithmetic operates on the calendar fields themselves — increment the month number, keep the day number if it exists, and clamp it back to the end of the month if it does not. Business days are a third family again: they are days, but the walk skips any day that falls on a Saturday or a Sunday, which means the answer depends on the weekday your start date happens to fall on. All three families are exposed here as one unit selector, with the net calendar days moved reported for every one of them, so you can always see how a 'six month' answer translates into a real day count.

How to use this calculator.

1. 01Enter the start date. It is written and read as ISO 8601 (YYYY-MM-DD), so 2026-07-29 means 29 July 2026 with no transatlantic ambiguity.
2. 02Choose Add to move forward in time or Subtract to move backward. Always enter the amount as a positive number and let this selector carry the sign.
3. 03Choose the unit. Use Days for an exact count, Weeks when the answer should land on the same weekday, Months or Years when you are working to a calendar milestone such as a contract term, and Business days when weekends must not count.
4. 04Enter how many. Whole numbers only, up to 200,000 of any unit.
5. 05Read the result date and its weekday, and check the 'What was adjusted' line — it tells you whether the day-of-month was clamped to a month end, or, in business-day mode, reminds you that public holidays were not removed.
6. 06Use the net calendar days figure to sanity-check a month-based answer, and the day-of-year figure when you need the ISO ordinal date form.

The formula.

Days and weeks are pure addition. The start date is converted to a count of milliseconds since the Unix epoch at UTC midnight, the offset in days is multiplied by 86,400,000 and added, and the result is converted back to calendar fields. Because both ends of that conversion are UTC, no daylight-saving transition can push the result across a midnight boundary. A week is exactly seven days, so weeks are computed as 7n days rather than by any separate calendar walk.

Months and years work on the calendar fields instead, because there is no fixed number of days in a month to add. The month index is converted to a single running count, y·12 + (m−1), the signed offset is added to that count, and the result is converted back to a year and a month. Years use the same path with the offset multiplied by twelve, which is why a year shift and a twelve-month shift always agree exactly. The day-of-month is then carried across unchanged if the target month is long enough to contain it, and clamped down to the last day of the target month if it is not — 31 March plus one month gives an invalid 31 April, so 30 April is returned. Because the offset is added to the running month count in a single step, two months from 31 January is 31 March rather than the 28 March you would get by applying one month twice.

Business days cannot be computed in closed form from the amount alone, because the answer depends on which weekday the start date falls on and on how many weekends the span happens to contain. The module walks one calendar day at a time in the chosen direction and decrements the remaining count only when it lands on a Monday through Friday, which is why a Friday plus one business day is the following Monday — three calendar days later, with two weekend days skipped.

The supporting figures are read off the result. Net calendar days is the signed difference between the two UTC midnights divided by 86,400,000. Day-of-year is the count of days from 1 January of the result's own year, so 1 January is day 1 and 31 December is day 365 or 366. Weekend days crossed counts Saturdays and Sundays over the half-open interval that runs from the earlier date up to but not including the later one — the same interval convention the date difference calculator uses for its business-day count, so the two pages can never disagree with each other.

A worked example.

Frequently asked questions.

References& sources.

1. [1]International Organization for Standardization, ISO 8601-1:2019 — Date and time: representations for information interchange, Part 1: Basic rules. Source of the YYYY-MM-DD calendar date form used for every date on this page and of the YYYY-DDD ordinal date form reported as the day-of-year output. Full text is a purchased standard; the abstract and scope are open.
2. [2]Oracle, Java SE API documentation — java.time.LocalDate.plusMonths and plusYears. Defines the month-end clamping rule this calculator implements: 'Add the input months to the month-of-year field; check if the resulting date would be invalid; adjust the day-of-month to the last valid day if necessary', illustrated with 2007-03-31 plus one month giving 2007-04-30 and 2008-02-29 plus one year giving 2009-02-28.
3. [3]python-dateutil documentation — relativedelta. Independent confirmation of the same clamping rule: 'If the result falls on a day after the last one of the month, the last day of the month is used instead', with date(2003, 1, 31) + relativedelta(months=+1) returning 2003-02-28 and date(2003, 1, 31) + relativedelta(months=+2) returning 2003-03-31 — the non-associativity this calculator reproduces.
4. [4]The Open Group, POSIX.1-2017 Base Specifications — strftime. Defines conversion specification %j as 'the day of the year as a decimal number [001,366]', the same ordinal day-of-year value this calculator reports.
5. [5]Internet Engineering Task Force, RFC 3339 — Date and Time on the Internet: Timestamps. The internet profile of ISO 8601; the basis for handling every date as a UTC-anchored instant so that daylight-saving transitions cannot move a calendar date.