Неправильный разбор строк

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

Строгая модель парсинга и отсутствие эвристик

Основной принцип работы Luxon при преобразовании строк заключается в отказе от неявных предположений. В отличие от стандартного Date.parse, который может интерпретировать неоднозначные строки по-разному в разных средах, Luxon требует явного указания формата.

Ключевые методы:

  • DateTime.fromISO()
  • DateTime.fromRFC2822()
  • DateTime.fromSQL()
  • DateTime.fromFormat()

Каждый из них работает только с определённым классом строк. Попытка передать неподдерживаемый формат приводит к созданию объекта:

  • DateTime.invalid

ISO-строки и частые ошибки интерпретации

Метод DateTime.fromISO() ожидает строго соответствующий ISO 8601 формат. Любые отклонения приводят к некорректному разбору.

Корректные примеры:

  • 2026-05-24
  • 2026-05-24T15:30:00
  • 2026-05-24T15:30:00+06:00

Типичные ошибки:

  • использование пробелов вместо T
  • отсутствие ведущих нулей
  • нестандартные разделители

Пример проблемной строки:

  • 2026/05/24 15:30

Такая строка не является ISO и не будет корректно интерпретирована через fromISO, даже если стандартный JavaScript Date её примет.

Локальные форматы и критичность шаблона

Метод DateTime.fromFormat() требует точного соответствия строкового представления шаблону, заданному разработчиком.

Например:

DateTime.fromFormat("24-05-2026 15:30", "dd-MM-yyyy HH:mm")

Любое несоответствие:

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

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

Особенность заключается в том, что Luxon не пытается «починить» строку, а просто возвращает невалидный объект.

Невидимые причины некорректного парсинга

Некоторые ошибки не связаны с очевидным несоответствием формата, но приводят к неправильному разбору строки.

1. Локаль и языковые различия

При использовании fromFormat() локаль влияет на интерпретацию месяцев и дней недели.

Например:

  • "янв" может быть валидным в русской локали
  • но полностью нераспознаваемым в en-US

Если локаль не установлена явно, используется системная или дефолтная, что создаёт нестабильность поведения.

2. Часовой пояс по умолчанию

Luxon использует системный часовой пояс или Zone по умолчанию. При парсинге строки без зоны:

  • 2026-05-24T10:00

результат зависит от текущей конфигурации окружения.

Это приводит к смещению времени без явного уведомления о проблеме, что визуально воспринимается как «неправильный разбор».

3. DST (переход на летнее время)

При попадании времени в «несуществующий» часовой диапазон (например, во время перехода часов):

  • результат может быть сдвинут
  • или помечен как невалидный

Luxon не корректирует такие значения произвольно, что отличается от поведения более «гибких» парсеров.

Частичная интерпретация и потеря данных

Некоторые форматы могут быть частично распознаны, но при этом часть информации игнорируется.

Пример:

DateTime.fromISO("2026-05-24 15:30")

Хотя строка похожа на ISO, пробел вместо T делает её некорректной. В результате:

  • дата может быть распознана частично
  • время может быть отброшено
  • или объект станет invalid

Такие случаи особенно опасны, так как визуально результат может выглядеть корректным.

Проверка валидности результата

Любой результат парсинга требует проверки:

  • isValid
  • invalidReason
  • invalidExplanation

Типовые причины:

  • unparsable
  • invalid input
  • out of range

Игнорирование этих свойств приводит к распространению некорректных дат по всей системе.

Различие между методами парсинга

Каждый метод Luxon интерпретирует строки по-своему:

  • fromISO() — строгий ISO 8601
  • fromRFC2822() — почтовые и HTTP-форматы
  • fromSQL() — SQL DATETIME / TIMESTAMP
  • fromFormat() — пользовательский шаблон

Ошибка выбора метода приводит к систематически неправильному разбору, даже если строка визуально «похожа» на корректную.

Неявные преобразования и их отсутствие

В отличие от стандартного JavaScript поведения:

new Date("24-05-2026")

Luxon не выполняет неявных преобразований. Строка:

  • не приводится к «примерному» формату
  • не нормализуется автоматически
  • не интерпретируется эвристически

Это исключает случайные ошибки, но усиливает требования к точности входных данных.

Работа с invalid объектами

При неудачном разборе возвращается объект DateTime, у которого:

  • isValid = false
  • отсутствуют корректные значения времени
  • внутренние поля содержат маркер ошибки

Такой объект продолжает участвовать в цепочках вызовов, что может маскировать проблему:

DateTime.fromISO("invalid-date").plus({ days: 1 })

Результат остаётся invalid, но без явного выброса исключения.

Каскадные ошибки в цепочках преобразований

Luxon является иммутабельным, поэтому каждая операция создаёт новый объект. При этом invalid-объект распространяется по всей цепочке:

  • парсинг строки
  • преобразование зоны
  • форматирование
  • арифметика дат

Ошибка, возникшая на этапе парсинга, сохраняется до финального шага, если не проверена заранее.

Проблемы неоднозначных форматов

Наиболее проблемные строки:

  • 05/06/2026 (неясно: май или июнь)
  • 2026-05-24 10:00:00 (не ISO)
  • 24.05.2026 (локальный формат)
  • 20260524 (компактный формат без разделителей)

Такие строки требуют строгого соответствия fromFormat, иначе интерпретация невозможна.

Влияние пробелов, разделителей и регистра

Luxon чувствителен к структуре строки:

  • двойные пробелы считаются нарушением формата
  • неправильные разделители (/ вместо -)
  • несоответствие регистра токенов (MM vs mm)

Ошибки в этих деталях приводят к полному отказу парсинга, а не к частичному исправлению.

Поведение при ошибках формата

При несовпадении формата Luxon:

  • не бросает исключение
  • возвращает invalid DateTime
  • сохраняет исходный контекст ошибки

Это делает ошибки менее заметными, но более предсказуемыми при системной обработке дат.

Оглавление