Days, weeks, months and weekdays between two dates.
Measuring the gap between two dates is one of the most-searched arithmetic problems on the open web. Payroll teams need it for accrual periods, parents calculate it for school enrolment cut-offs, lawyers use it for contract notice periods, project managers need it for milestone slippage, and anyone planning a wedding, a sabbatical, or a long trip wants to know how many sleeps remain. Mental shortcuts ("about three months and a bit") are quick but unreliable, especially across leap years or month-boundary crossings, and even spreadsheets disagree on whether a duration of "one month" should mean 30 days, 30.44 days, or "this same calendar day, next month." This calculator returns four complementary views of the same gap — total days, equivalent weeks, equivalent months and years, and a calendar decomposition into Y years, M months, D days — so that whichever interpretation your context demands, the right number is on screen. It also breaks out the count of weekdays versus weekends for use cases where only working days count, such as notice periods, leave requests, freight transit estimates, and court deadlines.
The arithmetic looks trivial — subtract the start from the end and divide by 86 400 000 milliseconds — but the surprises lie in the calendar layer above the millisecond layer. Total days is computed as the integer number of days between the two midnights, because raw millisecond subtraction can leak hours when the timezone has a daylight-saving transition between the two dates. The Y/M/D decomposition borrows from a higher denomination when a lower one goes negative: if the end day-of-month is less than the start day-of-month, we borrow the number of days in the previous month and decrement the month count; if months then go negative, we borrow twelve from the year count. Total months is computed from this decomposition (Y × 12 + M) so that the count matches the calendar, not a uniform 30.44-day approximation. Total weeks is total days divided by seven. Total years is total days divided by 365.25, the average length of a Gregorian year that accounts for the four-hundred-year leap cycle. The weekdays-only count walks the range one day at a time and excludes Saturdays and Sundays.
The form has three inputs: a start date, an end date, and a checkbox to include the end date itself in the count. The checkbox matters for leave requests and rental periods, which usually count both endpoints, and for freight ETAs, which typically do not. If you reverse the dates by mistake, the calculator silently flips them so the duration is always positive — there is no concept of a negative duration in the result. The defaults span 1 January 2025 to 1 May 2026, a sixteen-month window that crosses a calendar year so all four denominations show meaningful values. The result panel leads with total days, then displays weeks, months, years, and the Y·M·D decomposition, and finishes with the weekdays-only count for working-day calculations.
Take a wedding planned for 31 May 2026 from a today of 1 May 2026 with the end-date checkbox off: total days is thirty, total weeks is 4.29, total months is one, total years is 0.08, and the decomposition reads 0 y · 1 mo · 0 d because the day-of-month aligns. Now extend to a one-year notice period from 1 January 2025 to 1 January 2026: total days is 365 (no leap year crosses), total weeks is 52.14, total months is twelve, total years is 1.00, and Y·M·D is 1 y · 0 mo · 0 d. The weekdays-only count for that year is 261 — the standard "working days in a year" reference for many HR and payroll systems. Cross a leap year (1 January 2024 to 1 January 2025) and total days becomes 366 while the calendar decomposition is still 1 y · 0 mo · 0 d — same calendar duration, one extra physical day. This is the tension the calculator resolves: same calendar duration, different total-day count.
First, "one month" is not thirty days. Calendar months range from 28 to 31 days, and tools that approximate them as 30 or as 30.44 (the average) drift by up to ten percent over short windows. Use the Y·M·D decomposition when the calendar is what matters (birthdays, contract anniversaries) and total days when the duration in real time is what matters (interest accrual, project burn). Second, daylight-saving transitions add or remove an hour twice a year; the calculator works in calendar days rather than milliseconds to dodge this. Third, including the end date doubles the off-by-one bug surface. A five-day rental from Monday to Friday includes both Monday and Friday — switch the toggle on. A "delivery in five working days from Monday" usually means the next Friday — switch it off. Fourth, weekday counts ignore public holidays. If you need bank-business-day arithmetic, subtract holidays separately. Fifth, very long ranges (centuries) compound the 365.25-year approximation error; for genealogical or astronomical work, prefer the Y·M·D decomposition.
The "age in years" calculation is a special case of date difference where the end date is today; it shares the same Y·M·D logic but typically only the year count is shown to the user. Project tools (Gantt charts, Asana, Linear) all use date-difference internally to compute task duration; their twist is working-day arithmetic where weekends and corporate holidays are excluded. Financial instruments use day-count conventions that go further: 30/360, actual/360, actual/actual — all of which assume different counts for numerator and denominator depending on the bond market. Astronomy uses the Julian Day Number, a continuous count of days from 1 January 4713 BCE, that sidesteps the calendar entirely. UNIX time uses seconds since 1 January 1970 UTC. All of those resolve to the same physical duration when units are converted; the disagreement is only ever about which calendar layer to project the duration onto.