Date math sounds deceptively simple. "Add 90 days to July 15th" — for most of human history, you'd count months on your knuckles. But in code, it quickly gets treacherous. Is 90 days from February 1st April 1st or April 2nd? What if you're adding 30 calendar days to January 31st? Does 1 month after January 31st land on February 28th, February 29th, or March 3rd? Every major datetime library answers that question differently, and the wrong choice has quietly shipped incorrect billing dates, off-by-one report windows, and trial expirations that lasted a day too long.
This tool gives you a place to ask the question and get a predictable answer. Choose a start date, add or subtract any combination of years, months, weeks, days, hours, minutes, and seconds, and you see the result rendered in ISO 8601, your local timezone, and in plain English. The computation runs in the browser using standardized rules for calendar arithmetic (no surprising "30-day month normalization"), and it highlights exactly which fields changed, so you can spot when an operation rolled over a year boundary or clipped to a shorter February.
The subtraction side matters too. "What was 176 days before today?" is 6 months minus a few days in human terms, but "subtract 6 months" and "subtract 180 days" give different answers — one of those is correct and the other isn't, depending on whether you mean calendar-semantically or literally. The tool lets you work both ways and immediately see the gap.
Behind the start-and-end arithmetic sits a "difference" mode. You give it two dates and it tells you the gap in your unit of choice: total days, business days (Monday–Friday only, configurable holidays optional), total hours, or a breakdown of years+months+days+hours+minutes+seconds. That breakdown is what you actually want for "user-friendly" formatting: "1 year, 3 months, and 2 days left" reads differently and more honestly than "457 days left," even though they describe the same span.
A few quirks that bite people. Adding 365 days and adding 1 year are not the same operation — a leap day sitting in between shifts one and not the other. Adding 1 month to January 31st yields February 28th in most libraries because February has no 31st, and then adding 1 month back gives March 28th, not January 31st. That drift is why any moderately sophisticated date arithmetic should work with date + duration internally rather than repeatedly re-assigning. The tool shows you when that clipping happened so you can decide if it's what you wanted.
Real cases where this earns its keep: a 90-day trial ending on the right date (users notice), a subscription renewal exactly 12 cycles after signup, computing the last business day before quarter-end for report deadlines, verifying that an SLA window of "5 business days from ticket open" lands when your support team thinks it does, calculating the exact moment a 14-day countdown expires for a flash-sale timer, and sanity-checking that a cron expression like "0 0 1 * *" fires on the right day across a February boundary.