Calculating contract durations, project timelines, and deadlines. Working out exactly how many workdays (Mon–Fri) fall between two dates for invoicing or project estimation. Verifying age cut-offs (visa eligibility, school years, milestone birthdays). Adding "30 days net" or "90 day cooling-off" periods to a baseline date in a way that handles month-end correctly.

Inclusive vs exclusive end dates. "Days from Mon to Fri" is 4 if you count gaps, 5 if you count days. The toggle controls which convention; both are right depending on the question. Add/subtract order matters. Years and months apply first, then weeks and days. Adding "1 month + 1 day" to Jan 30 gives Mar 1 (Feb 30 → Feb 28/29 → +1), not Mar 2 — which is the calendar-safe convention almost every datetime library uses. Workdays don't include holidays. The calculation knows weekends but not bank holidays — adjust manually if it matters. "Total months" is approximate in the age view (years × 12 + months) — it ignores the trailing days. The Y/M/D figure is exact. UTC anchoring trades off with locale. A date in your local timezone might map to a slightly different UTC day. For most uses (deadlines, ages) UTC noon is the safer anchor; for to-the-minute timezone work use the timezone converter.

Daylight saving creates "missing" and "duplicate" hours twice a year. In a timezone observing DST, the day a clock springs forward has 23 hours (the 2-3 AM hour doesn't exist), and the day it falls back has 25 hours (1-2 AM happens twice). Calendar-day arithmetic across these dates is subtly wrong by an hour. For deadlines that fall on a DST transition, define them in UTC, not local time. Leap years are a three-rule pattern, not a four-year cycle. Divisible by 4 → leap, except divisible by 100 → not leap, except divisible by 400 → leap. So 2000 was a leap year, 1900 wasn't, 2100 won't be. The "every 4 years" version drifts by ~3 days per 400 years, which matters for long-running systems. Most date libraries handle this correctly; hand-rolled date math often doesn't. Workday calculations need a holiday calendar to be useful. The bare "exclude Saturdays and Sundays" approach (which this tool uses for the workdays metric) catches the right answer in about 80% of cases. The remaining 20% — bank holidays, religious observances, country-specific working Saturdays — needs a per-jurisdiction calendar. For shipping/SLA calculations, supplement with your operating-region holiday list rather than relying on weekday-only math. Age in years vs months vs days are different questions. "How old is this person?" usually means years (29). "How long ago was this event?" might want years + months + days (3 years, 7 months, 12 days). "How many days until this deadline?" wants integer days. Each of these calls for a different output format from the same start/end pair — pick deliberately based on the question being asked. ISO 8601 is the date format that won't betray you. 2026-05-21 is unambiguous worldwide and sorts correctly as text. 05/21/2026 (US) and 21/05/2026 (rest of world) look identical for dates in the first 12 days of the month, where they parse to different dates. Use ISO 8601 for any data that crosses borders, gets logged, or might be read by software.

Date Calculator

Days between two dates · add or subtract days/weeks/months/years from a date · age in years, months and days.

Mode

From

Include the end date in the count

Result

Enter input above to see the result.

What is this for?

Three things people actually want from a date calculator: the gap between two dates ("how many days until launch?"), shifting a date by a span ("90 days after invoice date"), and a precise age ("years, months, and days from a date of birth"). This tool does all three, in your browser, anchored to UTC noon so DST and timezone shifts don't quietly wrong the answer when you travel.

When to use it

Calculating contract durations, project timelines, and deadlines.
Working out exactly how many workdays (Mon–Fri) fall between two dates for invoicing or project estimation.
Verifying age cut-offs (visa eligibility, school years, milestone birthdays).
Adding "30 days net" or "90 day cooling-off" periods to a baseline date in a way that handles month-end correctly.

Common gotchas

Inclusive vs exclusive end dates. "Days from Mon to Fri" is 4 if you count gaps, 5 if you count days. The toggle controls which convention; both are right depending on the question.
Add/subtract order matters. Years and months apply first, then weeks and days. Adding "1 month + 1 day" to Jan 30 gives Mar 1 (Feb 30 → Feb 28/29 → +1), not Mar 2 — which is the calendar-safe convention almost every datetime library uses.
Workdays don't include holidays. The calculation knows weekends but not bank holidays — adjust manually if it matters.
"Total months" is approximate in the age view (years × 12 + months) — it ignores the trailing days. The Y/M/D figure is exact.
UTC anchoring trades off with locale. A date in your local timezone might map to a slightly different UTC day. For most uses (deadlines, ages) UTC noon is the safer anchor; for to-the-minute timezone work use the timezone converter.

Expert notes

Daylight saving creates "missing" and "duplicate" hours twice a year. In a timezone observing DST, the day a clock springs forward has 23 hours (the 2-3 AM hour doesn't exist), and the day it falls back has 25 hours (1-2 AM happens twice). Calendar-day arithmetic across these dates is subtly wrong by an hour. For deadlines that fall on a DST transition, define them in UTC, not local time.
Leap years are a three-rule pattern, not a four-year cycle. Divisible by 4 → leap, except divisible by 100 → not leap, except divisible by 400 → leap. So 2000 was a leap year, 1900 wasn't, 2100 won't be. The "every 4 years" version drifts by ~3 days per 400 years, which matters for long-running systems. Most date libraries handle this correctly; hand-rolled date math often doesn't.
Workday calculations need a holiday calendar to be useful. The bare "exclude Saturdays and Sundays" approach (which this tool uses for the workdays metric) catches the right answer in about 80% of cases. The remaining 20% — bank holidays, religious observances, country-specific working Saturdays — needs a per-jurisdiction calendar. For shipping/SLA calculations, supplement with your operating-region holiday list rather than relying on weekday-only math.
Age in years vs months vs days are different questions. "How old is this person?" usually means years (29). "How long ago was this event?" might want years + months + days (3 years, 7 months, 12 days). "How many days until this deadline?" wants integer days. Each of these calls for a different output format from the same start/end pair — pick deliberately based on the question being asked.
ISO 8601 is the date format that won't betray you. 2026-05-21 is unambiguous worldwide and sorts correctly as text. 05/21/2026 (US) and 21/05/2026 (rest of world) look identical for dates in the first 12 days of the month, where they parse to different dates. Use ISO 8601 for any data that crosses borders, gets logged, or might be read by software.