Decrement Calendar Date

When you subtract months from a date and the original day-of-month doesn’t exist in the target month. Examples: Mar 31 − 1 month → Feb has 28 (or 29) days, so clamp to Feb 28/29. May 31 − 1 month → Apr 30. Oct 31 − 8 months → Feb 28/29 again. The convention is to clamp to the last day of the target month, NOT spill over into the next month. Banks, HR systems, and date libraries (Moment, date-fns, Luxon) all follow this rule.

Two cases. (a) Year subtraction crossing leap → non-leap: Feb 29 2024 − 1 year. Target = Feb 29 2023, but 2023 isn’t a leap year. Tool clamps to Feb 28 2023. (b) Year subtraction landing on a leap year: Mar 1 2025 − 1 year = Mar 1 2024 (no special handling needed). The Gregorian calendar’s leap rule: every 4th year is leap, except every 100th (1900 was NOT leap), except every 400th (2000 WAS leap). JavaScript’s Date object knows all of this.

Days subtraction uses millisecond arithmetic (Date constructor with negative day count). The Date constructor handles month/year underflow automatically and correctly. So new Date(2024, 1, 29 - 365) gives Feb 29 2024 − 365 days = Feb 30 2023? No – Feb 28 2023. The constructor knows. Try the “Feb 29 leap − 1 year” sample to see the year-subtraction clamp, then add 365 days subtraction and compare.

Yes. Enter a negative number in any field and the operation inverts: year = −1 means add 1 year. The math is symmetric. But for general date addition, the sibling tool “Calendar Date Incrementer” is more direct (avoids cognitive overhead of negative inputs).

JavaScript’s Date object supports years 100,000 BC to 100,000+ AD via internal milliseconds. Negative years display oddly: the result shows year 0, -1, -2 etc. There’s no AD/BC indicator in HTML input type="date" elements either. For historical research before 1 AD, this tool’s UI doesn’t help – use a specialized historical calendar tool that handles the Julian/Gregorian transition (1582) and Anno Domini conventions.

The HTML input type="date" displays in local time, and most users think of dates as local (their March 31 is March 31, not “March 31 UTC”). UTC parsing introduces timezone offsets that shift the displayed date – e.g., user picks March 31, internal Date is March 31 UTC = March 30 23:00 in US Pacific, getDate() in local returns 30. Off by one. This is one of the most common JS date bugs in production code; we explicitly parse as local to avoid it.

Different uses. ISO (YYYY-MM-DD): universally machine-readable, sortable as a string, what databases want. US (MM/DD/YYYY): conventional US display. EU (DD/MM/YYYY): conventional European display, also Australia/UK. Long: human-readable with day-of-week and full month name, locale-aware via toLocaleDateString. Unix: seconds since 1970 Jan 1, useful for APIs and database timestamps. The Long format uses your browser locale (so EU users see EU-style dates with weekday name).

Yes – included in the Long format. Useful for “what day was Feb 13, 1995?” (Monday). Works for any year ±100,000 within JavaScript Date’s range. Spring DST doesn’t affect day-of-week since we work with midnight-local dates throughout.

Yes. All date math runs in your browser. Dates never leave your device. The download is generated in-memory and offered locally.