Why Date Math Is Harder Than It Looks
A "days between two dates" formula that comes out off by exactly one is one of the most common results people distrust, and usually the script or spreadsheet isn't the problem. Subtracting one date from another looks like third-grade arithmetic. It isn't. Leap years, timezone-crossing midnights, and a 442-year-old calendar reform all sit quietly underneath it.
If your own result is off by exactly one, check the counting convention before assuming a bug. "From March 1 to March 5" is 4 days if you're measuring the gap between them, or 5 if you're counting every calendar day inclusive of both ends, and a script or spreadsheet that assumes one convention while you expect the other will be off by exactly one, every time. That's a fencepost error, not a leap-year or timezone bug, and it's worth ruling out first before chasing anything below.
The leap year rule has three parts, not one
"Every four years" is the rule everyone learns and the rule that's wrong on its own. The Gregorian calendar's actual rule: a year is a leap year if divisible by 4, except century years, which are leap years only if divisible by 400. That's why 2000 was a leap year but 1900 and 1700 weren't. And why any date calculator that only checks "divisible by 4" will silently miscount every February around most century boundaries. The rule exists because a real solar year is about 365.2422 days, not 365.25. The extra correction keeps the calendar from drifting by roughly three days every four centuries.
Ten missing days, and a hundred years of disagreement about which ten
The Gregorian calendar itself only dates to 1582, when Pope Gregory XIII's reform deleted ten days to fix accumulated drift from the older Julian calendar, October 4, 1582 was followed directly by October 15. Catholic countries adopted it immediately; Britain and its colonies (including the future US) didn't switch until 1752, by which point the gap had grown to eleven days; Russia held out until 1918, after the revolution, by which point the gap was thirteen days. A calculator working across that boundary has to know which calendar a historical date was recorded in, or it will be off by well over a week.
Midnight isn't the same instant everywhere
"How many days between these two dates" gets genuinely ambiguous once timezones enter the picture, because a calendar date is really a timezone-relative label for a 24-hour window, not a fixed point in time. A flight that departs at 11pm and lands at 2am the next day locally might cross into a date that's two calendar days later, or the same day, depending on direction. Daylight saving transitions add another wrinkle: on the day clocks spring forward, one local hour never happens; on the day they fall back, one local hour happens twice. So "24 hours from now" and "this time tomorrow" can disagree by an hour, twice a year, in any timezone that observes DST.
What to actually do about it
If your goal is just double-checking a "days between" result, rule out the counting convention first, that single question explains more off-by-one results than any calendar quirk above. If you're building something that stores or compares dates across systems, standardize on a single unambiguous format rather than trusting either side to guess the convention. And if the dates in question cross a historical boundary, a timezone, or a daylight saving transition, treat hand-rolled arithmetic as suspect and check it against a calculator that already accounts for all of it.
Separately from the math, plain formatting causes its own errors: 03/04/2026 means March 4th in the US convention and April 3rd almost everywhere else, and nothing in the string itself disambiguates it. ISO 8601 (YYYY-MM-DD) exists specifically to remove that ambiguity. It sorts correctly as plain text and reads the same way in every locale. Which is why it's the standard for data interchange even in countries that write dates differently in everyday use.
Need to add, subtract, or find the gap between two dates without doing the calendar-reform arithmetic yourself? Try the date calculator.