Seven date-maths mistakes produce plausible answers: thirty-day months, month-end overflow, leap days, century rules, daylight saving, endpoint counting and Excel’s 1900 bug.
Date arithmetic looks like the easiest kind of arithmetic. It is not, because the calendar is irregular in five separate ways and every irregularity has a corresponding failure mode.
What makes these errors dangerous is that they are all small. None of them produces an obviously absurd result. They produce answers that are wrong by one, two or three days, plausible enough to be accepted, wrong enough to matter.
1. Treating a month as thirty days
Only four months have thirty days. Four have thirty-one in a row across July and August, February has twenty-eight or twenty-nine, and the pattern is genuinely arbitrary, a legacy of Roman calendar reform rather than any organising principle.
The error appears whenever someone converts between days and months by multiplying or dividing:
| Assumption | Reality | Error over a year |
|---|---|---|
| 1 month = 30 days | 30.44 days average | About 5 days |
| 1 month = 4 weeks | 4.35 weeks average | About 4.5 days |
| 1 year = 12 × 30 days | 365 or 366 days | 5 or 6 days |
| 1 quarter = 90 days | 90 to 92 days | Up to 2 days per quarter |
Where this bites hardest is subscription and rental periods. A “monthly” service billed every 30 days runs 12.17 cycles per year, not 12, which means one extra billing cycle roughly every six years. A four-weekly payroll runs thirteen cycles annually, not twelve, which is why four-weekly-paid staff receive two payments in one calendar month once a year.
The fix: use calendar months when the period is defined in months, and days when it is defined in days. Do not convert between them. The Date Add & Subtract Calculator keeps them as separate fields for exactly this reason.
2. Letting month-end dates overflow
Add one month to 31 January. There is no 31 February, so something must give.
The naive approach increments the month number and leaves the day alone, producing 31 February, which then normalises to 3 March, or 2 March in a leap year. This is wrong, and it is wrong in a way that varies by year, which makes it particularly nasty.
The correct behaviour is to clamp to the last valid day of the target month: 28 or 29 February. Every mainstream date library, database and spreadsheet does this.
| Operation | Clamped (correct) | Overflowed (wrong) |
|---|---|---|
| 31 Jan + 1 month | 28 or 29 Feb | 2 or 3 Mar |
| 31 Mar − 1 month | 28 or 29 Feb | 2 or 3 Mar |
| 31 May + 1 month | 30 Jun | 1 Jul |
| 31 Aug + 6 months | 28 or 29 Feb | 2 or 3 Mar |
There is a second-order trap here worth knowing about: clamping is not reversible. 31 January plus one month is 28 February, but 28 February minus one month is 28 January, not 31. Information is lost.
This matters for recurring schedules. A monthly payment set for the 31st will, in a naive system that chains each month from the last, drift permanently to the 28th after its first February and never recover. Well-built systems store the intended day-of-month separately and re-clamp from the original each time.
The fix: clamp, always. And in contracts, avoid “the same date each month” for any date after the 28th, specify “the last day of the month” or “the 28th” instead.
3. Forgetting leap days
Anyone born in 1990 has lived through nine leap days by 2026. That is nine days their age-times-365 estimate is short by.
The error grows with the span, which makes it worst in exactly the calculations where precision matters, long service periods, historical intervals, actuarial spans.
| Span | 365-a-year estimate | Actual days | Shortfall |
|---|---|---|---|
| 10 years | 3,650 | 3,652 or 3,653 | 2–3 days |
| 25 years | 9,125 | 9,131 or 9,132 | 6–7 days |
| 40 years | 14,600 | 14,610 or 14,611 | 10–11 days |
| 100 years | 36,500 | 36,524 or 36,525 | 24–25 days |
The fix: count real calendar days. Never multiply years by 365. Our Date Difference Calculator walks real dates, so every leap day in the span is counted automatically.
4. Getting the century rule wrong
The leap year rule has three clauses and most people only know the first:
- Divisible by 4 → leap year
- Unless divisible by 100 → not a leap year
- Unless divisible by 400 → leap year after all
So 1900 was not a leap year. 2000 was. 2100 will not be.
The 2000 exception is why an entire generation grew up with a mental model that only has the first clause, for anyone who came of age in the late twentieth century, the one century year they experienced followed the simple rule. The correction will not arrive until 2100.
This has one genuinely striking consequence: anyone born on 29 February 2096 will wait eight years for their next real birthday, because 2100 is skipped. The last time that happened was 1896 to 1904. We covered the full picture in born on 29 February.
The rule also has a subtler implication for anyone counting long spans: the calendar repeats exactly every 28 years within a century, but the pattern breaks across a non-leap century year. “My birthday falls on the same weekday every 28 years” is true for the next several decades and will stop being true after 2100.
5. Ignoring daylight saving
This one only affects people doing date maths in code or in a spreadsheet with time components, but when it strikes it is baffling.
The standard bug is to subtract two timestamps and divide by 86,400,000, the number of milliseconds in a day. If a clock change falls inside the span, one of those days is 23 or 25 hours long, so the division produces a fractional result and the rounding goes the wrong way. The answer comes out one day short or one day long.
It fails for a few weeks twice a year, in every country that observes daylight saving, and it passes every test written outside those windows.
The fix: normalise both dates to midnight UTC before subtracting, then divide. Every calculator on this site does this, which is why a span containing a clock change comes out right here.
There is a related trap in the other direction: adding days by adding milliseconds. Adding 86,400,000 milliseconds to the day before a clock change lands at 11 p.m. or 1 a.m. the following day, not midnight. Adding one to the calendar date instead always lands on the right day.
6. Off-by-one at the endpoints
Covered at length in days between dates, but it belongs on this list because it is the most frequent error of the seven.
From 1 March to 3 March is two days (exclusive, the interval) or three days (inclusive, counting both endpoints). Both are correct answers to different questions, and the failure is not choosing wrongly, it is not noticing that a choice exists.
The fix: compute both, and know which one your document means. Legal drafting has vocabulary for this, “clear days”, “beginning with”, “excluding the date of”, and where none of it appears, take the earlier deadline.
7. Excel thinks 1900 was a leap year
This is a real, documented, deliberate bug in Microsoft Excel that has survived since the 1980s.
Excel stores dates as serial numbers counting from 1 January 1900. Its calendar includes 29 February 1900, a date that never existed, because 1900 was not a leap year under the Gregorian rule.
It was not an oversight. Lotus 1-2-3, the dominant spreadsheet at the time, had the bug, and Excel replicated it deliberately for file compatibility. Microsoft has documented the decision publicly and kept it, on the grounds that fixing it would shift every date serial number by one and break decades of existing spreadsheets.
The practical consequences:
- Any span crossing 28 February 1900 comes out one day too long.
- Serial number 60 corresponds to a non-existent date.
- Excel’s day-of-week calculations for January and February 1900 are wrong.
- Dates before 1 January 1900 cannot be represented at all in the default system.
For genealogy, historical research, or anything touching the turn of the twentieth century, this is a live problem. If your span crosses that date, subtract one from Excel’s answer.
Checks that catch nearly everything
- A span that is a multiple of seven days must start and end on the same weekday
- Add the parts back together, they must reconstruct the original span
- Count a short version by hand off a calendar and compare
- Check whether any month-end clamping happened, and whether it should have
- Confirm your leap-year list, including the century rule
- State which endpoint convention you used, in writing
Red flags in someone else's answer
- A day count that is an exact multiple of 365
- A month figure ending in .0 for a span crossing February
- A result of 3 March from adding a month to 31 January
- Two spans of the same length reported as different, or vice versa
- A weekday that changed after adding a multiple of seven days
- Any span crossing early 1900 computed in a spreadsheet
The pattern behind all seven
Every one of these errors comes from the same source: treating the calendar as regular when it is not.
Months are unequal. Years are unequal. Days are occasionally unequal. The rules that correct for the Earth’s orbit are themselves irregular, with exceptions layered on exceptions. And on top of all that, some conventions are genuinely ambiguous rather than merely complicated.
The reliable approach is to work on real calendar dates, one day at a time, and never convert between units by multiplying. That is slower to do by hand, which is exactly why calculators exist, and why the ones worth using tell you which conventions they picked. Every tool on this site names its own, on the page, where you can see it.