The complete guide to adding and subtracting days from a date
Almost every plan you make comes down to one simple question: what date is a certain number of days from today? A project deadline is 45 days from kickoff. A contract requires a 90-day notice period. An invoice is due on net-30 terms. A warranty expires two years after purchase. Behind each of these everyday moments sits the same small piece of arithmetic β date math β and getting it exactly right matters more than most people realize. One miscounted day can mean a missed filing deadline, a late payment fee, or a contract that renews when you meant to cancel it. This guide explains how date calculations really work, the traps that catch people out, and how to do them reliably every time.
Why adding days to a date is trickier than it looks
Adding days feels like ordinary addition, but dates are not ordinary numbers. Months have irregular lengths β 28, 29, 30 or 31 days β so you cannot simply add a number to the day-of-month and be done. Adding 30 days to January 15 does not give you "January 45"; you must roll through the end of January and into February, and the answer changes depending on whether February has 28 or 29 days that year. Add 30 days to January 15, 2026 and you land on February 14, 2026. Do the same in leap year 2024 and you land on February 13, because February 2024 had an extra day. The mechanics are simple once you see them, but doing them in your head across month and year boundaries is exactly where mistakes creep in.
There is a second, subtler trap: time zones and daylight saving. Many online calculators and spreadsheet formulas compute with local time, and on the night clocks change, a "day" can be 23 or 25 hours long. Naive calculations can then land one day off β the classic off-by-one error. Professional date tools do their arithmetic in UTC (Coordinated Universal Time), where every day is exactly 24 hours, and only convert to a human-readable date at the very end. That is the approach DateJump uses, which is why its results stay exact even across daylight-saving transitions.
How to add days to a date, step by step
The reliable manual method works like this. Start from your start date and add the days one month at a time: first use up the days remaining in the current month, then consume whole months, then land in the final month. For example, to add 90 days to September 29, 2026: September has 1 day left after the 29th (the 30th), October contributes 31, November contributes 30 β that is 62 days used, leaving 28, which lands you on December 28, 2026. The same walk works for subtraction in reverse. For larger offsets it helps to think in chunks of whole years first (365 or 366 days), then months, then days. In practice, of course, nobody wants to do this by hand for every deadline β a dedicated date calculator does the walk for you in milliseconds and shows the day of the week too, which matters when a result lands on a weekend.
Adding weeks, months and years
Weeks are the easy unit: one week is always exactly seven days, so adding weeks is just adding multiples of seven. Months and years are where judgment calls appear. When you add one month to January 31, what should the answer be? February has no 31st, so every serious date library clamps to the last day of the target month: January 31 plus one month becomes February 28 (or February 29 in a leap year). This is called month-end clamping, and it is the behavior of SQL databases, Java, Python's dateutil and virtually every calendar API. The alternative β overflowing into March β surprises users and breaks billing logic, which is why clamping is the standard. The same rule applies to years: February 29, 2024 plus one year becomes February 28, 2025.
A related question is what "one month" even means as a duration. For date arithmetic it means "the same day number in the next month" (with clamping), not "30 days". Adding one month to March 15 gives April 15, which is 31 days later, while adding one month to April 15 gives May 15, which is 30 days later. If you need a fixed duration instead, use days or weeks. This distinction is why DateJump keeps months/years and days/weeks as separate units rather than converting everything to days behind your back.
Business days vs calendar days
Many real-world deadlines are counted in business days, not calendar days. A "10 business day" delivery promise starting on a Friday means the parcel arrives two full weeks later, not the following Monday week. Business-day arithmetic simply skips Saturdays and Sundays as it counts. So 5 business days after Friday, January 2 is Friday, January 9 β the weekend days are stepped over, not counted. Some industries also skip public holidays, which vary by country and region; a general-purpose calculator skips weekends and leaves holiday calendars to specialized tools, but for most planning the weekend skip covers the need. When a date calculator offers a "business days only" toggle, it is converting your offset into a walk that counts only Monday-to-Friday landings.
Inclusive vs exclusive day counting β the deadline trap
One of the most common sources of date disputes is whether the start day itself counts as day one. In exclusive counting β the default in most calculators β the start date is day zero, so "30 days from September 29" lands on October 29. In inclusive counting, the start date counts as day one, so the same phrase lands on October 28. Legal notices, subscription trials and project sprints all disagree on which convention they use, which is why contracts spell it out ("within 30 days after receipt" vs "30 days including the date of receipt"). When the stakes are high, always confirm the convention β and when a calculator offers both modes, match it to your document's wording. A one-day difference is exactly the kind of thing that decides whether a notice was served on time.
Calendar weeks and the ISO week date
Beyond the date itself, planners often need the calendar week: which numbered week of the year does the result fall in, and which Monday starts that week? The international standard, ISO 8601, defines week 1 as the week containing the first Thursday of the year, with weeks running Monday to Sunday. Under this system a year has 52 or occasionally 53 weeks, and dates near New Year can belong to the previous or next year's week numbering β January 1, 2027, for example, falls in week 53 of 2026. Payroll cycles, sprint planning and manufacturing schedules all run on week numbers, so seeing the ISO week next to your result date saves a separate lookup.
Leap years, explained once and for all
A year is a leap year if it is divisible by 4, except century years, which must also be divisible by 400. So 2024 and 2028 are leap years, 1900 was not, and 2000 was. The extra day, February 29, exists because Earth takes about 365.2422 days to orbit the sun; without the correction our calendar would drift by a day every four years. For date arithmetic the practical consequence is small but real: any offset that crosses a February 29 lands one day later in the calendar than the same offset in a non-leap year. If your calculation spans February, double-check whether that year is a leap year β or let the calculator handle it.
Everyday uses for a date calculator
Once you start looking, date offsets are everywhere. Freelancers quote "delivery in 14 business days". HR teams compute probation end dates, notice periods and leave balances. Travelers count the 90/180-day Schengen allowance. Parents track pregnancy weeks and vaccination schedules. Students count down to exams. Investors track lock-in periods and maturity dates. Developers compute sprint end dates and certificate expirations. In each case the question is the same β start date plus offset equals result β and the value of a purpose-built tool is that it answers with the day of the week, the weeks-and-days breakdown and bulk results in one glance, instead of making you chain three separate lookups.
Bulk date calculations
Sometimes one date is not enough. A project manager may need milestone dates for a dozen different offsets from kickoff; a teacher may need exam dates for several "N days after term start" values; a finance team may need every invoice due date in a batch. Doing these one at a time is slow and error-prone. Bulk mode solves it: paste a list like "+30 days", "-2 weeks", "90", "3 months" and get a full table of result dates, each with its day of the week and distance from the start date. Exporting that table to CSV drops it straight into a spreadsheet or project plan. The parsing is forgiving β signs and units are optional, and plain numbers default to days β because the goal is speed, not ceremony.
Common mistakes and how to avoid them
- Counting on your fingers across month ends. Humans are bad at remembering which months have 30 vs 31 days. Use the knuckle trick (months on knuckles have 31 days) or, better, a calculator.
- Forgetting leap years. Any calculation crossing February in a leap year shifts by a day. Check divisibility by 4 (and the century rule).
- Mixing up inclusive and exclusive counting. Decide which convention your deadline uses before you calculate, not after.
- Ignoring weekends in "business day" promises. Five business days is usually seven calendar days. Count only MondayβFriday landings.
- Trusting local-time math near daylight-saving changes. If a tool ever gives you a result one day off in March or October, this is why. UTC-based math does not have this bug.
- Assuming a month is 30 days. "One month from March 15" is April 15 (31 days later). For fixed durations, use days or weeks.
How DateJump computes your answer
DateJump performs every calculation in UTC, so daylight-saving transitions can never shift a result. Day and week offsets are added as exact 24-hour steps. Month and year offsets use month-end clamping, the same rule used by databases and programming-language date libraries worldwide. Business-day mode walks forward or backward one day at a time, counting only Monday-to-Friday landings. Inclusive mode counts your start date as day one; exclusive mode (the default) counts it as day zero. Bulk mode parses each line independently, so one malformed line never breaks the rest of the table. Everything runs locally in your browser β your dates are never uploaded anywhere β and the tool is free with no account, no limits and no watermarks.