«15.03.2024» — привычная для России запись даты, где день идёт первым, а год последним. Но стоит скопировать дату из англоязычной таблицы или API в формате «03/15/2024», и при невнимательном чтении месяц и день легко перепутать местами — а разница между датами посчитается неверно, при этом без единой ошибки в коде.
Откуда берётся путаница DD.MM.YYYY и MM/DD/YYYY
В России, как и в большинстве Европы, принят порядок «день.месяц.год» — 5 марта пишут как 05.03.2024. В США же стандартна запись «месяц/день/год»: 03/05/2024 — та же строка, но уже про 3 марта. Разница дат, посчитанная по неверно прочитанной дате, может ошибиться на несколько недель, и при этом никакой программной ошибки не возникнет — просто получится не тот ответ.
Единственный формат без двойного толкования — ISO 8601
Запись 2024-03-05 (год-месяц-день) однозначна в любой стране мира, поэтому именно её использует большинство API, баз данных и логов. Если есть возможность выбирать формат при обмене датами между системами — ISO 8601 избавляет от всей этой путаницы навсегда.
Часовые пояса и границы суток
Если даты включают время, а не только календарный день, разница в часовых поясах может сдвинуть подсчёт дней на единицу: 23:30 по Москве и 20:30 по Лондону в один и тот же момент могут оказаться в разных календарных днях — в зависимости от того, в каком поясе вести отсчёт.
Зачем это нужно
- Рассчитать точное количество дней до дедлайна или от даты начала проекта.
- Проверить, действительно ли договор или гарантия ещё не истекли.
- Найти ошибку в отчёте, где дата пришла из системы с другим порядком компонентов.
Почему «разница в месяцах» — понятие с двойным дном
Если отнять месяц от 31 марта, результат неочевиден: 31 февраля не существует, поэтому одни системы округляют до 28 февраля, а другие переносят «лишние» дни на 3 марта. Оба варианта по-своему логичны, но дают разные числа — стоит иметь это в виду, сверяя расчёт с другим калькулятором или банковской выпиской.