Date Difference Calculator

Inclusive and exclusive counting

The days between 1 March and 5 March is either four or five, depending on whether both endpoints are counted. Both conventions are used and neither is wrong.

Exclusive counting, giving four, is the arithmetic difference and is what most software returns. Inclusive counting, giving five, is what people usually mean when they ask how many days something lasts.

Hotel bookings, hire agreements and event durations frequently use one convention while the customer assumes the other, which is a recurring source of billing disputes.

Working days

Business day calculations exclude weekends and public holidays, and public holidays vary by country, by region and by year.

England and Wales, Scotland and Northern Ireland have different bank holidays. US federal holidays differ from state holidays. Any working-day calculation is only as good as the holiday list behind it.

Contracts frequently specify working days for notice periods and payment terms, and the definition should be in the contract. Where it is not, the local convention applies and the two parties may have different local conventions.

Months, which are not a fixed length

Adding a month to 31 January gives a date that does not exist. Conventions differ: clamp to 28 or 29 February, or roll over to 2 or 3 March.

Most software clamps, which means adding one month twice from 31 January gives 31 March in some implementations and 28 March in others, since the second addition starts from the clamped date.

That non-associativity is genuinely surprising and it is why date arithmetic in software is a well-known source of bugs. For anything contractual, specifying the actual dates rather than a number of months avoids it entirely.

Daylight saving and leap seconds

Days are not all 24 hours long. In territories observing daylight saving, one day a year has 23 hours and one has 25.

Which means a duration in hours across a clock change is not the number of days times 24. Anything scheduling across those dates needs to work in absolute time rather than in local time.

Leap seconds have been inserted into UTC periodically to keep it aligned with the Earth's rotation, and a decision has been taken to discontinue them by 2035. They affect systems requiring sub-second accuracy and nothing else.

Calendar changes in historical dates

The switch from the Julian to the Gregorian calendar happened at different times in different countries. Catholic Europe changed in 1582; Britain and its colonies in 1752, dropping eleven days; Russia not until 1918.

Which means a date before those changes is ambiguous unless the calendar is specified. British historical dates are frequently annotated Old Style or New Style for this reason.

The new year also moved. Until 1752, the legal year in England began on 25 March, so a date in January 1700 by contemporary reckoning is January 1701 by ours. Historical date arithmetic without accounting for this produces confident and wrong answers.

For anything that will be relied on, storing and calculating in UTC and converting to local time only for display avoids most of the traps at once. Time zones move, daylight saving rules change by legislation with limited notice, and a date stored as local time in a database becomes ambiguous the moment either happens. This is why software that gets dates right does the arithmetic in absolute time and treats the calendar as a presentation layer, and why software that does not eventually produces a meeting scheduled an hour out.