Date Calculator - Single Date Operations

Adding a duration to a date is not commutative and not associative, which is the single fact that governs how this tool behaves. It applies years first, then months, then days, because that order is the convention in most date libraries and in the drafting of contracts and statutes. Year and month steps operate on the calendar field and can overflow: adding one month to January 31 produces March 3 in a common year and March 2 in a leap year, because February has no thirty-first day and the surplus rolls forward; adding one year to February 29, 2024 yields March 1, 2025. Day steps, by contrast, are pure counting and never overflow. Change the order - 30 days then 1 month, versus 1 month then 30 days - and you can land on different dates from the same start. The results are calendar days, not business days and not banking days, which is where most real errors enter. A 90-day contractual window and a 90-business-day window differ by roughly 36 days, and 5/7 conversions ignore public holidays entirely. Legal drafting also distinguishes the counting rule: many statutes exclude the first day and include the last, so a 30-day notice served on March 1 expires March 31, not March 30. Other caveats: the arithmetic runs in local civil time, so daylight-saving transitions shift the wall-clock instant by an hour without changing the date; historical dates before Gregorian adoption in a given country are not converted; and the ISO 8601 output uses UTC conversion, which can display the neighbouring day for users in eastern time zones.

Calendar arithmetic of this kind is old and legal in origin rather than mathematical. Roman practice counted inclusively from a named day, a habit preserved in the phrase a die - from the day - and in the confusion it still causes; medieval and early modern instruments counted terms in named feast days rather than day counts. The shift to arithmetic day counting followed the Gregorian reform of 1582, which made day-of-month arithmetic reliable, and the growth of bills of exchange in early modern commerce, where a bill drawn at ninety days after sight required an unambiguous maturity date and merchants relied on printed usance and days-of-grace tables to compute it. The rules this calculator implements were formalised again in the twentieth century, first in commercial-law codification and then in software. Day-count conventions such as 30/360 and actual/365 were standardised for bond interest so that competing parties would compute the same accrual period. On the computing side, date-add semantics became de facto standards through language libraries: the C standard library mktime function, which normalises out-of-range calendar fields, established the roll-forward behaviour that makes January 31 plus one month become March 3, and JavaScript adopted the same normalisation when the Date object was introduced with the language in 1995. ISO 8601, first published in 1988, later added a duration syntax of the form P1Y2M10D that expresses exactly this year-month-day triple, and its revisions in 2000, 2004 and 2019 refined the interchange rules that modern scheduling systems rely on.