Date Calculator

Counting from the 1st of a month to the 8th produces exactly 7 full nights between the two dates — the exclusive count, which is the number of complete 24-hour periods that separate them. But a contract, notice period or lease that says "within 7 days" is very often counting inclusively, treating both the start and end date as counted days rather than as boundary markers with nothing between them — under that reading, the same 1st-to-8th span could be interpreted as 8 days. Neither convention is universally "correct"; they answer genuinely different questions, which is why this tool shows both figures rather than picking one and leaving the other to be worked out separately whenever the specific wording matters.

Excluding Saturdays and Sundays from a day count is close to a universal convention across contracts, legal deadlines and shipping estimates, since the five-day working week is close to globally standard. Public holidays are a different matter entirely — they vary not just by country but frequently by state, region or even city within one country, with no single authoritative calendar this tool could apply correctly for every user. Excluding weekends while leaving holiday handling to the user is the honest approach: for a deadline where a specific public holiday genuinely matters, checking the relevant jurisdiction's official holiday calendar separately is a necessary extra step this calculator cannot substitute for.

Adding one calendar month to 31 January cannot literally produce "31 February," since February never has 31 days — the near-universal convention, and the one this tool follows, is to land on the last valid day of the target month instead, giving 28 February in an ordinary year or 29 in a leap year. This has a genuinely surprising consequence worth knowing about: adding a month to 31 January and then subtracting a month from the result does not necessarily return you to 31 January, since the intermediate date already lost the extra days January had that February does not. This is not a bug specific to this tool — it is an unavoidable consequence of months having different lengths, and any date library handling month arithmetic faces the identical ambiguity.

A frequent, subtle bug in date tools comes from treating a plain calendar date like "15 March 2026" as a specific instant in UTC time, then converting that instant to the viewer's local time zone for display — which can shift the displayed date backward or forward by a day depending on how far the local time zone sits from UTC, producing a date calculator that quietly gets the wrong day near a time-zone boundary. This tool treats dates as plain calendar dates with no time-of-day or time-zone component attached at all, exactly the way a paper calendar works, which sidesteps that entire class of bug rather than needing to carefully manage time zones to avoid it.