How this is worked out
Two questions look the same and are not. How many days between two dates has one exact answer. How many years, months and days does not, because months are different lengths — so the answer depends on which months you crossed, and every tool has to pick a convention.
The convention here is the one people mean: advance whole months from the start date for as long as that lands on or before the end date, then count the leftover days. From 31 January to 1 March is 1 month and 1 day, because one month from 31 January is 28 February. The alternative — subtracting the day fields and borrowing — produces "1 month and −2 days", which is not an answer.
Adding months has the same problem, sharper. One month after 31 January cannot be 31 February. This tool clamps to the last day of the target month and tells you it did, which is what finance and legal systems do for exactly this reason. Some tools silently roll into 3 March instead, and a deadline that quietly moves two days is worse than one that is obviously approximate.
Days are counted from calendar fields, never by subtracting timestamps. On the day a clock goes forward, one calendar day is 23 hours long — divide the millisecond difference by 86,400,000 and you get 0.958 days, which floors to zero. That single bug is why so many date tools are off by one twice a year.
Working days are counted inclusively: both the start and end dates are included if they are working days. That is the convention for notice periods and delivery estimates, and it is why the figure is one higher than a simple subtraction.
A worked example
- Mode
- Days between
- From
- 2026-08-24 (Monday)
- To
- 2026-11-22 (Sunday)
- Days apart
- 90
- Counting both ends
- 91
- Calendar breakdown
- 0y 2m 29d
- Working days, Sat/Sun weekend
- 65
- One month after 31 January 2026
- 28 February 2026 (clamped)
Why "one month later" has no correct answer
Ask a calendar what one month after 31 January is and there is no honest answer, because 31 February does not exist. There are only conventions, and the two in common use disagree by up to three days.
Clamping to the last day of the target month — giving 28 February, or 29 in a leap year — is the convention used by contract law, loan schedules and payroll almost everywhere. It preserves the important property that the result is inside the month you asked for. Overflowing instead, so that 31 January plus a month becomes 3 March, breaks that: you asked for February and got March.
This page clamps, and says so in the readout whenever it happens. The alternative is a tool that gives you a date two days later than your contract does without ever mentioning it, and dates that are quietly wrong are worse than dates that are obviously uncertain.
Working days, and why the holidays are not built in
Weekends are easy to remove; public holidays are not. They differ by country, by state or province within a country, by industry, and they move — the UK gains one for a coronation, the US observes a Saturday holiday on the preceding Friday, Australia's vary by state, and Canada's vary by province.
A built-in holiday list would be right for some visitors, wrong for most, and silently out of date within a year. So this tool asks you for the dates that apply to you. Paste them in as YYYY-MM-DD separated by commas; any that fall on a weekend are not double-counted.
The count is inclusive of both ends. If a notice period runs from Monday to the following Friday, that is ten working days, not nine — and the difference between those two numbers is the sort of thing that ends up in a dispute.
The off-by-one that appears twice a year
The tempting way to count days is to subtract one date from the other and divide by the number of milliseconds in a day. It works for most of the year and then quietly fails.
On the day the clocks go forward, the calendar day is 23 hours long. Subtracting gives 0.958 days, which rounds or floors to zero — so a tool reports that two different dates are the same day. Going back, a 25-hour day can push a count one too high. It is the single most common bug in date software, and it is invisible unless you happen to test across a clock change.
This calculator works from calendar fields — year, month, day — anchored at noon UTC, so a clock change of an hour in either direction cannot move the date. The arithmetic is tested against real daylight-saving transitions in both hemispheres rather than only against ordinary weeks.
Leap years, and being born on 29 February
A year is a leap year if it divides by four, except centuries, except centuries that divide by 400. That is why 1900 was not a leap year and 2000 was — a distinction that broke a great deal of software in both of those years.
People born on 29 February have a birthday in only one year in four. For everyday purposes the UK, US, Canada and Australia all treat the birthday as falling on 1 March in common years, which is what this tool does. Some jurisdictions use 28 February for specific legal thresholds such as reaching the age of majority, so if a date matters legally, check the rule that applies rather than trusting any calculator.
The age calculation counts completed years, which is how age works everywhere in daily life: you are 39 until the day you turn 40, not from the moment you pass 39 and a half.
Assumptions and sources
- Standard
- ISO 8601 for date format and week numbering. Weeks start on Monday and week 1 is the week containing the first Thursday of the year, which is why 1 January can fall in week 52 of the previous year.
- Time zones
- None. All arithmetic is anchored at noon UTC so daylight saving cannot move a date. The calculator deliberately does not do time-of-day maths — the time zone planner does.
- Month arithmetic
- Clamped to the last valid day of the target month, the convention used in contract, payroll and loan schedules. Reported in the readout whenever it applies.
- Verification
- Tested in tools/test/datetime.mjs across real daylight-saving transitions in both hemispheres, leap years, century years, and month-end clamping.