The dates that break software
If you are seeding fixtures, make sure some of these land in your range. Each one has broken production systems repeatedly:
- 29 February. Only exists in leap years.
new Date(2025, 1, 29)silently becomes 1 March in JavaScript. - 31 December and 1 January. Week-number and fiscal-year logic fails here.
- The day a DST change happens. Some local days have 23 or 25 hours, so "add 24 hours" and "add one day" are different operations.
- Dates before 1970. Negative Unix timestamps, which some libraries mishandle.
A range that spans several years will hit the first three by itself.
Which format for which job
| Format | Example | Use for |
| --- | --- | --- |
| ISO 8601 | 2026-08-31 | storage, APIs, sorting, fixtures |
| Local | 31.08.2026 | display to a user |
| Unix | 1788134400 | timestamp columns, arithmetic |
ISO is the only one of the three that sorts correctly as a string, which is why it is the default here.
Uniform across the range
Every day between the two bounds is equally likely, and both endpoints are included. Nothing is transmitted — generation happens in your browser.
Questions
Which format should I use for test data?+
ISO 8601 (`2026-08-31`). It sorts correctly as plain text, it is unambiguous about day and month order, and every database and language parses it. Reserve the local format for what a user sees.
Why does the range include both ends?+
Because that is what people mean when they say "between 1 January and 31 December". Exclusive upper bounds are a common off-by-one source in generated fixtures — the last day silently never appears.
Are the dates in UTC?+
Dates are generated at day resolution in UTC, so a date never shifts by a day depending on where the browser is. The Unix output is midnight UTC for that day.
Can I generate dates for load testing?+
Up to a thousand at a time here. For millions, take the range logic into your own seeding script — copying a million lines through a browser text area is the wrong tool.