Строгий режим

Строгий режим в Luxon связан не с отдельным глобальным переключателем, а с философией обработки даты и времени: любые неоднозначные или некорректные входные данные не приводят к «догадкам», а фиксируются как невалидные значения. Это принципиально отличает библиотеку от стандартного Date в JavaScript, который часто скрывает ошибки за автоматическими преобразованиями.

В основе работы Luxon лежит объект DateTime, который всегда имеет состояние валидности. Любой результат парсинга может быть либо корректным временем, либо специальным невалидным объектом.

Ключевой принцип:

  • корректный ввод → DateTime с валидными полями
  • некорректный ввод → DateTime, но с isValid = false
const dt = luxon.DateTime.fromISO("2024-13-40");

dt.isValid; // false
dt.invalidReason; // "unparsable"
dt.invalidExplanation; // более подробное описание

Такой подход исключает «тихие ошибки», когда дата превращается в неожиданное значение.

Отличие строгой модели Luxon от встроенного Date

Встроенный объект Date в Jav * aScript:

  • автоматически нормализует некорректные значения
  • «перепрыгивает» через переполнения
  • возвращает Invalid Date только в крайних случаях
  • не предоставляет детальной причины ошибки

Пример поведения Date:

new Date(2024, 13, 40);
// корректируется в реальную дату, а не вызывает ошибку

Luxon же не выполняет автоматической коррекции входных данных при разборе строк:

  • неправильный формат → невалидный результат
  • лишние символы → невалидный результат (в строгих сценариях)
  • несоответствие шаблону → невалидный результат

ISO-разбор и строгая интерпретация формата

Метод fromISO является одним из наиболее строгих способов создания даты.

Он ожидает корректную ISO-8601 строку:

const a = luxon.DateTime.fromISO("2026-05-23T10:20:30");

a.isValid; // true

Любое отклонение от формата может привести к невалидному объекту:

const b = luxon.DateTime.fromISO("23-05-2026");

b.isValid; // false

Важная особенность:

  • отсутствует «догадка формата»
  • отсутствует попытка альтернативного парсинга
  • используется только строгая интерпретация ISO-структуры

Строгий разбор произвольных форматов через fromFormat

Наиболее показательный механизм строгого режима проявляется в fromFormat.

const dt = luxon.DateTime.fromFormat("2024/05/23", "yyyy-MM-dd");

Несмотря на визуальную схожесть, формат не совпадает с шаблоном. Результат:

dt.isValid; // false

Принцип строгого сопоставления шаблону

Luxon не пытается:

  • переставить разделители
  • игнорировать лишние символы
  • угадывать структуру строки

Сравнение идёт символ в символ согласно маске формата:

  • yyyy → строго 4 цифры года
  • MM → строго 2 цифры месяца
  • dd → строго 2 цифры дня

Любое отклонение ломает валидность результата.

Невалидные даты как основной механизм защиты

Вместо исключений библиотека использует объект ошибки внутри DateTime.

Типовые причины невалидности:

  • unparsable — строка не соответствует формату
  • invalid input — входные данные не могут быть интерпретированы
  • out of range — значения выходят за допустимые пределы календаря
  • unsupported zone — неверная временная зона
const dt = luxon.DateTime.fromObject({
  year: 2024,
  month: 99,
  day: 10
});

dt.isValid; // false
dt.invalidReason; // "invalid input"

Проверка валидности как обязательный этап

Строгий режим предполагает явную проверку результата перед использованием.

Основные свойства:

  • isValid — итоговое состояние
  • invalidReason — тип ошибки
  • invalidExplanation — текстовое описание проблемы
const dt = luxon.DateTime.fromISO("invalid-date");

if (!dt.isValid) {
  console.log(dt.invalidReason);
}

Такой подход делает обработку данных предсказуемой и устраняет скрытые дефекты на раннем этапе.

Поведение при операциях над невалидными объектами

Любая операция с невалидным DateTime сохраняет невалидное состояние.

const dt = luxon.DateTime.fromISO("bad input");

const result = dt.plus({ days: 5 });

result.isValid; // false

Это критически важный элемент строгой модели:

  • ошибка не маскируется
  • состояние не «исправляется» автоматически
  • цепочка вычислений сохраняет факт некорректности

Строгая работа с временными зонами

Luxon требует явного и корректного указания зоны, если она используется.

const dt = luxon.DateTime.fromISO("2024-05-23T10:00", {
  zone: "Europe/Paris"
});

Если зона некорректна:

const dt = luxon.DateTime.fromISO("2024-05-23T10:00", {
  zone: "Invalid/Zone"
});

dt.isValid; // false

Строгий режим здесь выражается в отсутствии fallback:

  • нет автоматической замены зоны на UTC
  • нет подстановки локальной зоны
  • нет попытки «угадать» регион

Обработка пользовательского ввода в строгой модели

При работе с внешними источниками данных (формы, API, файлы) строгий режим требует предварительной валидации входа.

Типовой поток:

  1. получение строки
  2. попытка парсинга через Luxon
  3. проверка isValid
  4. либо использование значения, либо отклонение
function parseDate(input) {
  const dt = luxon.DateTime.fromISO(input);

  if (!dt.isValid) {
    return null;
  }

  return dt;
}

Такой подход предотвращает накопление ошибок в бизнес-логике.

Поведение форматирования после строгого парсинга

Если объект валиден, форматирование выполняется предсказуемо:

const dt = luxon.DateTime.fromISO("2024-05-23T10:00:00");

dt.toFormat("yyyy-MM-dd"); // "2024-05-23"

Если объект невалиден:

const dt = luxon.DateTime.fromISO("bad");

dt.toFormat("yyyy-MM-dd"); // "Invalid DateTime"

Это сохраняет строгую модель на всех этапах жизненного цикла объекта.

Стратегии проектирования систем на основе строгого режима

При использовании Luxon в строгом режиме формируется архитектурный паттерн «fail-fast»:

  • ошибки выявляются на границе системы
  • невалидные данные не проходят в доменную логику
  • каждая дата сопровождается проверкой валидности

Характерные практики:

  • централизованный парсинг дат
  • единый слой валидации входных данных
  • запрет на использование «сырых» строк в бизнес-логике
  • хранение только нормализованных DateTime

Последствия игнорирования строгой модели

Отсутствие проверки isValid приводит к:

  • распространению невалидных объектов по системе
  • некорректным вычислениям временных интервалов
  • ошибкам форматирования на поздних этапах
  • скрытым дефектам, проявляющимся только в UI или отчётах

Luxon не препятствует таким ошибкам, но делает их явными и детектируемыми на ранней стадии, что и формирует основу строгого режима работы с датой и временем.

Оглавление