Отсутствующий функционал

Day.js проектируется как минималистичная альтернатива тяжёлым библиотекам работы с датами, и именно в этой минималистичности заключается основной массив отсутствующего функционала. Архитектура ядра сознательно ограничена набором базовых операций: создание даты, форматирование, простые арифметические операции и доступ к компонентам времени. Всё, что выходит за пределы этого набора, либо исключено, либо вынесено в плагины.

Ядро Day.js представляет собой компактную обёртку над нативным объектом Date. В нём отсутствуют сложные подсистемы, характерные для более «тяжёлых» решений:

• нет встроенного календарного движка;
• отсутствует система сложных правил локальных календарей;
• нет собственного временного движка с учётом исторических корректировок;
• минимизирована логика интерпретации входных строк.

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

Отсутствие встроенной поддержки часовых поясов

Одним из наиболее заметных ограничений является отсутствие полноценной работы с часовыми поясами в ядре. Day.js по умолчанию оперирует локальным временем среды выполнения и UTC-представлением, не предоставляя механизмов:

• конвертации между произвольными часовыми поясами;
• учёта исторических изменений часовых зон (DST transitions);
• работы с IANA Time Zone Database без подключаемых расширений.

Функциональность временных зон реализуется исключительно через плагины, и без них библиотека остаётся «часозонно-нейтральной».

Это означает, что операции вроде «получить время в Tokyo с учётом локальных правил» невозможны без дополнительного слоя логики.

Ограничения работы с длительностями и интервалами

Базовый функционал не включает полноценную модель длительностей. Отсутствуют следующие возможности:

• строгая типизация интервалов времени как отдельного объекта;
• арифметика сложных интервалов (например, нормализация месяцев в дни с учётом календарных правил);
• поддержка цепочек интервалов с автоматической коррекцией переполнений;
• анализ пересечений интервалов.

Добавление или вычитание времени реализуется через простые методы (add, subtract), но их семантика ограничена:

• отсутствует учёт неоднозначных календарных периодов;
• месяцы и годы обрабатываются приближённо, без календарной точности в пограничных случаях.

Это делает невозможными некоторые сценарии финансовых и научных расчётов без дополнительных библиотек.

Парсинг и валидация дат

Встроенный парсинг Day.js строго ограничен. В ядре отсутствует:

• полноценный строгий парсер RFC-форматов;
• глубокая валидация неоднозначных строк;
• восстановление некорректных дат с интеллектуальной интерпретацией;
• поддержка кастомных грамматик разбора дат.

Парсинг строк опирается в основном на возможности Date.parse и ограниченные внутренние алгоритмы. Это приводит к следующим ограничениям:

• различное поведение в разных JavaScript-движках;
• невозможность гарантированного разбора нестандартных форматов;
• отсутствие устойчивого механизма обработки «грязных» данных.

Расширенные сценарии разбора реализуются через плагины вроде customParseFormat, но в базовой поставке отсутствуют.

Календарные системы и локализация

В ядре Day.js нет поддержки альтернативных календарных систем. Недоступны:

• исламский календарь;
• еврейский календарь;
• китайский лунный календарь;
• любые гибридные или исторические календари.

Также отсутствует полноценная модель локализации календарных правил:

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

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

Ограничения API манипуляции датами

Манипуляции датами в Day.js намеренно упрощены. Отсутствуют:

• сложные цепочки преобразований с промежуточными состояниями;
• ленивые вычисления изменений;
• транзакционная модель изменений даты;
• возможность отката операций (rollback);
• сравнение истории изменений объекта даты.

Каждая операция возвращает новый объект, но система не отслеживает происхождение изменений. Это делает невозможным анализ «путей трансформации» даты.

Также отсутствуют:

• дифференциальные операции с детализацией по компонентам (например, точное разложение разницы на календарные элементы с учётом всех правил);
• автоматическое выравнивание по рабочим/нерабочим дням;
• встроенные бизнес-календарные правила.

Отсутствие продвинутых временных вычислений

Day.js не включает функциональность, характерную для систем планирования и временной аналитики:

• нет встроенных cron-выражений;
• отсутствует система повторяющихся событий;
• нет планировщика интервалов;
• отсутствует модель временных окон (time windows);
• нет механизма событийного времени (event scheduling engine).

Любые подобные сценарии требуют внешней реализации или интеграции сторонних библиотек.

Отсутствие специализированных временных моделей

Ядро не предоставляет:

• модели финансового времени (торговые дни, биржевые календари);
• научных временных шкал с высокой точностью интервалов;
• поддержки leap seconds (високосных секунд);
• исторических временных реконструкций с учётом изменения календарных систем.

Все эти области полностью вынесены за пределы ответственности библиотеки.

Компенсация через систему плагинов

Архитектурная стратегия Day.js заключается в том, что отсутствующий функционал не реализуется внутри ядра, а подключается точечно через плагины. Это формирует модульную модель расширения:

• timezone-плагин добавляет поддержку IANA зон;
• duration-плагин вводит работу с длительностями;
• advancedFormat расширяет форматирование;
• customParseFormat добавляет гибкий парсинг;
• relativeTime реализует относительные выражения времени.

Однако даже при использовании плагинов сохраняется принцип: ядро не становится полнофункциональной временной платформой, а остаётся минималистичным базисом.

Такой подход приводит к предсказуемому поведению, но одновременно оставляет значительный объём функциональности вне стандартного API, требуя явной сборки возможностей под конкретный сценарий использования.