How To

How to Calculate the Number of Days Between Two Dates

Counting days between dates by hand, in a spreadsheet, or instantly - plus the inclusive-versus-exclusive trap that makes two correct answers differ by one.

How to Calculate the Number of Days Between Two Dates

Counting days between two dates sounds trivial until you try it. Months have different lengths, leap years exist, and the answer changes by one depending on a question nobody thinks to ask: does the first day count?

Here is how to do it properly — by hand, in a spreadsheet, or instantly — and how to avoid the off-by-one that causes most of the arguments.

The same two dates, 1 March to 5 March, counted two ways DURATION — how much time passes 1st 2nd 3rd 4th 5th = 4 The first day is a boundary, not a day OCCUPANCY — days you actually use 1st 2nd 3rd 4th 5th = 5
Both answers are right. Hotel nights and countdowns use the top row; holiday entitlement and anything billed per day uses the bottom.

The inclusive-versus-exclusive trap

From 1 March to 5 March. Is that four days or five?

Both answers are correct, for different questions:

  • Four — the duration. How much time passes between the two points. This is what almost every calculator and spreadsheet returns by default.
  • Five — the count of days involved. The 1st, 2nd, 3rd, 4th and 5th. This is what you want for billing a hotel, counting holiday entitlement, or anything where both endpoints are days you actually occupy.

The rule worth remembering: duration is exclusive, occupancy is inclusive. If both endpoints are days you are using, add one to whatever the calculator tells you.

This is not pedantry. It is the difference between invoicing for four nights and five, and it is the single most common reason two people counting the same period disagree.

The fastest way

Enter both dates in our days between dates calculator. It returns the exact count, handles leap years correctly, and has an option for working days only. It runs entirely in your browser, so nothing you type is sent anywhere.

Doing it by hand

For two dates in the same year: count the days remaining in the first month, add the whole months between, then add the days into the final month.

From 12 March to 8 June:

  • Rest of March: 31 − 12 = 19
  • April: 30
  • May: 31
  • Into June: 8
  • Total: 19 + 30 + 31 + 8 = 88 days

Across a year boundary, from 20 November 2025 to 14 February 2026:

  • Rest of November: 30 − 20 = 10
  • December: 31
  • January: 31
  • Into February: 14
  • Total: 86 days

Month lengths, since everyone forgets: 31 days in January, March, May, July, August, October and December. 30 in April, June, September and November. February has 28, or 29 in a leap year.

The knuckle trick works if you cannot remember: make a fist and count across your knuckles and the dips between them, starting at January on the first knuckle. Knuckles are 31-day months, dips are 30 — with February as the exception.

Leap years, correctly

Most people know “every four years”. The full rule has two exceptions, and they matter for long spans:

  • Divisible by 4 → leap year.
  • Unless divisible by 100 → not a leap year.
  • Unless also divisible by 400 → leap year after all.

So 1900 was not a leap year. 2000 was. 2100 will not be.

If your span crosses a February in a year ending in 00, check it properly. This is exactly the edge case that produced a crop of software bugs in early 2000 — a great deal of code implemented only the first rule, and 2000 happened to give the right answer anyway, so nobody noticed until 2100 became someone else’s problem.

In Excel and Google Sheets

Both treat dates as sequential numbers, so plain subtraction works:

=B1-A1

If the result displays as a date rather than a number, the cell has inherited date formatting. Set it to General or Number and the count appears — the value was always right.

For working days, excluding weekends:

=NETWORKDAYS(A1, B1)

Note that NETWORKDAYS is inclusive of both endpoints, unlike plain subtraction. That inconsistency inside the same spreadsheet catches people constantly, and produces totals that are quietly off by one per row. To exclude public holidays, list them in a range and pass it as the third argument.

For a working week that is not Monday to Friday, NETWORKDAYS.INTL takes a weekend code as its third argument — useful for Middle Eastern working weeks where Friday and Saturday are the weekend.

What people are usually actually asking

  • Notice periods and deadlines. Check whether the contract says calendar days or working days — on a 30-day period the difference is about nine days, which is the difference between meeting a deadline and missing it.
  • Hotel and rental billing. Nights, not days. Four nights between the 1st and the 5th, and this is what the invoice should say.
  • Holiday entitlement. Working days, inclusive, minus public holidays.
  • Pregnancy and medical dating. Usually counted in completed weeks from a specific start date, not in calendar months.
  • Age or anniversaries. A different calculation entirely — use an age calculator, which handles month-boundary arithmetic properly rather than dividing by 365.
  • Project timelines. Working days, and remember the end date is usually inclusive.
  • Countdown to an event. Exclusive — today is not one of the days remaining.

Why dividing by 365 is wrong

Converting a day count to years by dividing by 365 drifts by roughly a day every four years, and by well over a week across a few decades.

Dividing by 365.25 is closer but still wrong, because it assumes every fourth year is a leap year and ignores the century rule entirely.

For anything legal, medical or financial, count the actual calendar rather than approximating. The approximation is what produces “your policy expired yesterday” surprises and disputes over whether someone had turned eighteen.

Time zones and daylight saving

Day counts are unaffected by daylight saving. A day is a calendar day regardless of whether it contained 23 or 25 hours, so the count between two dates does not change when the clocks go forward.

Time zones are different. If one date is recorded in one zone and the other in another, they can be a full day apart depending on how the timestamps were captured. This is a common source of off-by-one errors in software that stores dates as timestamps rather than as calendar dates — and it is why booking systems occasionally show a stay as one night longer or shorter than expected.

When both dates are plain calendar dates with no time attached, none of this applies.

Join the discussion

Held for review before it appears. Links are not allowed and your email is never published.