Даты, на которых ломается софт
Если наполняете тестовые данные, проследите, чтобы часть из них попала в диапазон. Каждая не раз роняла продакшен:
- 29 февраля. Есть только в високосные годы. В JavaScript
new Date(2025, 1, 29)молча превращается в 1 марта. - 31 декабря и 1 января. Здесь падает логика номеров недель и финансовых лет.
- День перевода часов. В некоторых локальных сутках 23 или 25 часов, поэтому «прибавить 24 часа» и «прибавить сутки» — разные операции.
- Даты до 1970 года. Отрицательные Unix-метки, с которыми часть библиотек обращается неверно.
Диапазон в несколько лет накроет первые три пункта сам.
Какой формат под какую задачу
| Формат | Пример | Для чего |
| --- | --- | --- |
| ISO 8601 | 2026-08-31 | хранение, API, сортировка, фикстуры |
| Локальный | 31.08.2026 | показ пользователю |
| Unix | 1788134400 | колонки с метками времени, арифметика |
Из трёх только ISO правильно сортируется как строка — поэтому он и стоит по умолчанию.
Равномерно по диапазону
Каждый день между границами равновероятен, обе границы включены. Ничего не передаётся — генерация идёт в браузере.
Вопросы
Какой формат брать для тестовых данных?+
ISO 8601 (`2026-08-31`). Он правильно сортируется как обычная строка, однозначен по порядку дня и месяца и разбирается любой базой и любым языком. Локальный формат оставьте для того, что видит пользователь.
Почему диапазон включает обе границы?+
Потому что именно это имеют в виду, говоря «с 1 января по 31 декабря». Исключающая верхняя граница — типичный источник ошибки на единицу в сгенерированных данных: последний день просто никогда не появляется.
Даты в UTC?+
Даты генерируются с точностью до дня в UTC, поэтому дата не сдвигается на сутки в зависимости от часового пояса браузера. Unix-вывод — это полночь UTC соответствующего дня.
Подходит для нагрузочного тестирования?+
Здесь до тысячи за раз. Для миллионов перенесите логику диапазона в собственный скрипт наполнения: гонять миллион строк через текстовое поле браузера — не тот инструмент.