Paste a list of dates, one per line, set a day offset, and the calculator returns each line shifted by that many days. Each row stays on its own line in the output, paired with its original input and a status flag, so a single bad entry never wipes out the rest of the batch. Inputs must be ISO YYYY-MM-DD; anything else is flagged as an error on that row only. The math runs in UTC, so the answer does not drift across time zones. For one-off shifts use the days between two dates view; for Unix-epoch lists, see the bulk timestamp converter.
Common use cases
- Bulk-shift contract renewal dates. A vendor renegotiates and pushes every renewal out by 30 days. Paste the renewal list, set days to 30, and copy the result column back into the contract tracker. Bad rows surface inline so you can fix them in the source spreadsheet without re-running the whole batch.
- Project replan after a slip. A milestone slipped one week. Paste every dependent due-date, set days to 7, and read the new dates. Use the result column to update the plan in one paste rather than editing each cell individually. The line numbers in the output map back to the original list order.
- Compute due dates from a list of invoice dates. Net-30 terms shift each invoice date forward by 30 days to its due date. Paste the invoice list, set days to 30, and the result column is the due-date column. For net-15 or net-60, change the offset and re-run; the input box keeps its content.
- Backdate a list of received dates. A batch of records arrived late and the true event was 3 days earlier. Paste the received-on list, set days to -3, and the result column gives the corrected event dates. Negative offsets work the same way as positive ones, with no sign-handling on your side.
- Spot-check a list of weekday claims. Paste a list of dates and set days to 0 to validate that every entry parses cleanly as ISO. Rows that fail to parse light up with an error; clean rows echo through unchanged. To then look up the weekday for any cleaned date, use the weekday calculator.
How it works
The calculator splits the textarea on newlines, trims each line, and runs every non-empty line through the ISO-date parser. Lines that parse get the day offset applied via date-fns addDays and the result is formatted back to YYYY-MM-DD. Lines that fail to parse return an error string in place of a result, so the row count of the output always matches the row count of the input.
- Paste the date list. One ISO date per line in the textarea. Empty lines and trailing whitespace are tolerated; the trim runs before parsing. Lines must be in YYYY-MM-DD form, the only format the underlying parser accepts.
- Set the day offset. Type a whole number into the Days field. Positive shifts forward, negative shifts backward, zero passes the date through unchanged. Fractional values truncate to integer behavior because date-fns addDays expects whole days.
- Read the result table. The output renders one row per input line with the line number, the original text, and either the shifted ISO date or an error message. The result updates live as you type, so there is no submit button.
- Copy the result column. Select the result cells and paste back into your spreadsheet. Errors stay visible inline so you can fix the source list and re-run; the calculator does not silently drop bad rows.
Worked examples
Shift three project dates by 30 days
Paste 2026-04-27, 2026-05-04, 2026-05-11 on three lines and set days to 30.
Result: The calculator returns 2026-05-27, 2026-06-03, 2026-06-10.
Each input is shifted forward by 30 calendar days. The first two cross a month boundary; April has 30 days and May has 31, so the same offset of 30 lands on different day-of-month values across the three rows.
Backdate three month-ends by one day
Paste 2026-01-31, 2026-02-28, 2026-03-31 and set days to -1.
Result: The calculator returns 2026-01-30, 2026-02-27, 2026-03-30.
A negative offset subtracts calendar days. The result preserves the row order, so line 2 in the output is the shift of line 2 in the input regardless of whether the offset is positive or negative.
Mixed valid and invalid input formats
Paste 2026-04-27, then "Apr 28, 2026", then "2026/04/29" and set days to 7.
Result: Line 1 returns 2026-05-04. Lines 2 and 3 both return the error "Enter a valid ISO date."
The parser accepts only YYYY-MM-DD. Slashes, written month names, and any other locale-specific format fail; the rest of the batch keeps running. Reformat the failing rows at the source and re-paste.
Empty line and an unparseable token in the middle
Paste 2026-01-01, an empty line, 2026-02-13, then "bad" and set days to 10.
Result: Line 1 returns 2026-01-11; line 3 returns 2026-02-23. Lines 2 and 4 surface the error "Enter a valid ISO date."
Empty lines count toward line numbering but fail the parse check, so the row stays in the output as an error rather than being silently dropped. Delete the blank line at the source if you need a clean batch.
Duplicate input rows pass through twice
Paste 2026-12-25, 2026-12-25, 2027-01-01 and set days to 14.
Result: The calculator returns 2027-01-08, 2027-01-08, 2027-01-15.
Duplicates are not deduplicated. Each input line maps to one output row, in the same order, even when two rows hold the same value. Run the result through a spreadsheet de-dupe step if you need uniqueness.
Edge cases & gotchas
- Only YYYY-MM-DD parses. The underlying parser is strict ISO 8601 calendar-date form. Slash-separated (2026/04/29), month-name (Apr 28, 2026), two-digit-year (26-04-29), and locale-specific orderings all fail with the same error message. The strictness is intentional: it rules out ambiguous inputs like 03/04/2026 where US and European readers disagree on the month. Convert at the source before pasting.
- Invalid rows do not abort the batch. A row that fails to parse returns an error string in its result cell and the rest of the batch keeps running. The output row count always matches the input row count, including blank lines. This is the difference between this tool and a single-row date-add field, which would simply refuse to compute when the input is malformed.
- Duplicate input rows are preserved. The calculator does not deduplicate. Two identical lines produce two identical output rows on consecutive line numbers, both shifted by the same offset. Spreadsheets and calendar import flows usually want this behavior so the row count matches; pipe through a de-dupe step downstream if you need uniqueness.
- The day offset is unbounded. Days accepts any integer the number input will hold, including very large positive or negative values. A shift of 36500 (roughly a century) computes without complaint and returns a date that far out. There is no input cap; correctness depends on date-fns handling the resulting JavaScript Date, which is reliable across the range you are likely to need.
Frequently asked questions about Batch Date Calculator
What input formats does the calculator accept?
Only ISO 8601 calendar dates in YYYY-MM-DD form. Slashes, written month names, two-digit years, and locale-specific orderings all fail with a per-row error. Reformat at the source before pasting; spreadsheets can usually export an ISO column with one formula change.
What happens to rows that fail to parse?
They surface as an error string in the result column for that row. The line number, the original input, and the error message all render so you can spot the problem. Other rows in the batch keep computing; one bad line never blocks the rest.
Are duplicate dates removed?
No. Each input line maps to exactly one output row, in the original order, even when two lines hold the same value. The tool preserves row count for predictable copy-paste back into spreadsheets. De-duplicate downstream if you need it.
Does the day offset accept negative numbers?
Yes. A negative offset shifts each date backward by that many calendar days. The behavior is symmetric with the positive case and uses the same date-fns addDays primitive; there is no separate "subtract" mode.
Why do my pasted dates with slashes fail?
The parser is intentionally strict ISO 8601. Slash-separated dates like 03/04/2026 are ambiguous between US (March 4) and European (April 3) readings, and the calculator refuses to guess. Convert to YYYY-MM-DD in your source spreadsheet first; most spreadsheet apps support an ISO format token.
Does the result depend on my time zone?
No. Inputs are read as plain calendar dates with no time component, anchored to UTC midnight, and the offset adds calendar days without crossing any zone or DST math. A user in any time zone gets the same result for the same paste and the same offset.
How is this different from a single-row date-add field?
A single-row field handles one date at a time. This tool handles a batch in one paste, with row-level error reporting, so a list of fifty contract dates becomes a list of fifty shifted dates in seconds. The single-row use case is better served by a basic date-add field when you also want a quick span count.
Glossary
- ISO 8601 calendar date
- The YYYY-MM-DD format defined by ISO 8601. Year, month, and day are zero-padded to four, two, and two digits and joined with hyphens. The only input format the calculator accepts.
- Day offset
- The integer number of calendar days to add to each input row. Positive shifts forward, negative shifts backward. The same offset applies to every row in the batch.
- Per-row error
- An error string attached to a single output row when its input fails to parse. The rest of the batch continues to compute; the error stays inline so the row count in the output matches the input.
- Strict parser
- A date parser that accepts only one canonical input format (here, YYYY-MM-DD) and rejects every other layout. The tradeoff is fewer surprises from ambiguous inputs at the cost of pre-processing your source data.