Date Calculator

Date math: why days are exact but months are only an estimate

Days are exact; months and years are estimates

The number of days between two dates can be computed exactly — it is the absolute interval between two points in time, with no ambiguity (as long as you fix whether the endpoints are included). That is the safe, unambiguous part of any date calculation.

But "how many months" has no single answer, because months have different lengths. The label means different day counts depending on which months you span.

The same label "1 month" can therefore mean 28 to 31 days. So the tool gives an exact day count, and converts months and years using average lengths that are clearly marked as estimates (a month is treated as 30.44 days, a year as 365.25 days). You will not see both 30 and 31 collapsed into "1 month" with no stated basis.

When you need an exact "number of months", do not use the conversion — use calendar rules: advance month by month, handling month-end appropriately (Jan 31 plus a month is Feb 28 or Mar 2 depending on the system). Employment length, rental periods and billing cycles should use the calendar method; the difference against the average-length estimate is usually a few days, which is enough to matter for contracts.

Month-end overflow when adding months

The easiest place to go wrong in date arithmetic is the month handling when you add:

The tool applies calendar rules to this overflow. Note this is not the only correct implementation: some systems choose to "spill into the next month" (Mar 31 + 1 month = May 1). For contract due dates, billing dates and subscription renewals, you must confirm which rule your business expects before trusting any computed date.

Four conventions you must pin down

1. Include the boundary dates or not. "How many days from the 1st to the 3rd" could be 2 (the interval) or 3 (inclusive). Leave days, hotel nights and project durations each use a different convention. This is the number-one cause of date errors in real systems.
2. Time zone. A bare date usually carries no time-zone issue, but anything touching "today" or "now" does. A cross-time-zone server computing "today" in UTC can be a day off from your local date. This matters especially when a date picker returns a local date while the server thinks in UTC.
3. Working days versus calendar days. "30 days apart" and "30 working days" are completely different. Working-day math must exclude weekends and public holidays, and holidays vary by region and year — you need the right calendar data, not a hand rule.
4. Daylight saving time. In DST regions some dates are 23 or 25 hours. Pure date math is unaffected, but a "from time X to time Y" duration can differ by an hour. (China does not observe DST, so domestic work can ignore this one.)

Practical uses

• Project duration. Use days and state inclusivity. For cross-month projects, list the start and end dates rather than "X months".
• Billing and due dates. Add months by calendar, matching the overflow rule to the business agreement.
• Age and anniversaries. "Full 18 years" needs the exact day, and must handle Feb 29 births in non-leap years.
• Countdowns. Target date minus today, watching the inclusivity convention.
• Statistics windows. For year-over-year comparison, align "the same period last month" by calendar, not by shifting 30 days.

How the tool works

Pick a start and end date for the exact day gap plus week, month and year estimates; pick a base date and add days, months and years for the result. Both parts update live, and all date math runs locally in your browser with no upload.