После почти 30 лет борьбы с проблемным объектом Date JavaScript получил долгожданное решение. Temporal API только что достиг четвёртой стадии в процессе TC39 и официально вошёл в стандарт ECMAScript 2026. Это не просто очередное улучшение - это фундаментальный пересмотр того, как мы работаем с датами и временем в JavaScript.

Если вы когда-либо теряли часы из-за ошибок с таймзонами, боялись мутировать объекты Date или ломали голову над парсингом дат - эта статья для вас. Temporal решает все эти проблемы сразу, и сейчас самое время разобраться, что изменилось и как это использовать.

Почему старый Date был кошмаром

Объект Date в JavaScript - это пример того, как не нужно проектировать API. Он был создан под влиянием Java ещё в 1995 году и с тех пор буквально ломает мозг разработчикам по всему миру. Главная беда в том, что Date мутирует - когда вы вызываете методы вроде setMonth(), вы изменяете исходный объект, что приводит к непредсказуемому поведению в коде.

Вторая проблема - это адская путаница с таймзонами. Date всегда работает в UTC внутри, но выводит значения в локальной таймзоне пользователя. Когда вы создаёте встречу на 31 января в 10:00 и добавляете месяц, дата может неожиданно сдвинуться из-за часовых поясов. Разработчики годами решали эту проблему через библиотеки вроде Moment.js, которые сами по себе стали балластом для проектов.

Основные боли с Date:

• Мутация объектов - методы изменяют исходный объект, вместо того чтобы возвращать новый
• Неявные таймзоны - Date скрывает информацию о часовом поясе, работая только в UTC
• Странный парсинг - одна и та же строка дает разные результаты в разных браузерах
• Неудобная работа с интервалами - нет встроенного способа узнать длительность между датами
• Хрупкость с календарями - невозможно корректно работать с разными календарными системами

Что такое Temporal и как он решает эти проблемы

Temporal - это полностью переработанный API для работы с датами, временем, таймзонами и календарями. Вместо одного объекта Date он предлагает набор специализированных типов, каждый из которых отвечает за свою задачу. Это значит, что дата, время и момент во времени больше не будут перепутаны в одном неудобном контейнере.

Самое главное изменение - immutability. Все объекты Temporal неизменяемы, как строки в JavaScript. Когда вы добавляете месяц к дате, вы получаете новый объект, а исходный остаётся нетронутым. Это делает код предсказуемым и избавляет от целого класса багов.

Темпоральные типы разделены по смыслу:

• PlainDate - просто дата без времени (например, день рождения)
• PlainTime - просто время без даты (например, время открытия магазина)
• PlainDateTime - дата и время, но без привязки к таймзоне
• ZonedDateTime - полное описание момента с таймзоной
• Instant - точный момент во времени в UTC
• Duration - длительность между двумя моментами

В отличие от Date, Temporal явно работает с таймзонами. Когда вы создаёте ZonedDateTime, вы точно указываете, в каком часовом поясе это время. При работе с DST (переводом часов) API ведёт себя корректно - если вы добавляете час к времени, которое попадает в пропущенный час (когда часы переводят вперёд), Temporal автоматически сдвинет время на правильный момент.

Сравнение подходов:

Код вместо слов: примеры Temporal

Лучше один раз увидеть, как это работает, чем читать описания. Посмотрите, насколько проще становится работа с датами.

Простой пример - получить сегодняшнюю дату и добавить день:

const today = Temporal.Now.plainDateISO();
const tomorrow = today.add({ days: 1 });
console.log(tomorrow.toString()); // 2026-03-08

С Date это выглядело бы намного сложнее и содержало мутацию. А теперь более сложный пример с таймзонами - создаём встречу в Берлине и добавляем месяц:

const meeting = Temporal.ZonedDateTime.from('2026-03-07T10:00[Europe/Berlin]');
const nextMonth = meeting.add({ months: 1 });
console.log(nextMonth.toString()); // 2026-04-07T10:00:00+02:00[Europe/Berlin]

Заметьте, что таймзона явно указана, и при переводе часов API справляется корректно. Вот ещё один пример - работа с DST (когда в Лондоне часы переводят вперёд с 00:30 на 02:30):

const zdt = Temporal.ZonedDateTime.from(
  "2026-03-29T00:30:00+00:00[Europe/London]"
);
const plus1h = zdt.add({ hours: 1 });
console.log(plus1h.toString());
// "2026-03-29T02:30:00+01:00[Europe/London]" (01:30 не существует)

API автоматически пропустил несуществующий час и перешёл к правильному времени. С Date такое было немыслимо.

Хотите узнать длительность между двумя моментами? Для этого есть метод since():

const start = Temporal.PlainTime.from('09:00');
const end = Temporal.PlainTime.from('17:30');
const duration = end.since(start);
console.log(duration.toString()); // PT8H30M (8 часов 30 минут)

И работа с UTC - тут всё просто и понятно:

const instant = Temporal.Instant.from("2026-02-25T15:15:00Z");
console.log(instant.toString()); // "2026-02-25T15:15:00Z"

// Переводим в разные таймзоны
console.log(instant.toZonedDateTimeISO("Europe/London").toString());
// "2026-02-25T15:15:00+00:00[Europe/London]"

console.log(instant.toZonedDateTimeISO("America/New_York").toString());
// "2026-02-25T10:15:00-05:00[America/New_York]"

Поддержка в браузерах и среды выполнения

Хорошая новость - Temporal уже доступен в современных браузерах, хотя поддержка ещё не полная. Это означает, что вы можете начать использовать его прямо сейчас, но нужно проверить поддержку или использовать полифилл для старых окружений.

Текущее состояние поддержки выглядит так:

• Firefox 139 (май 2025 и позже) - полная поддержка
• Chrome 144 (январь 2026 и позже) - полная поддержка
• Edge 144 (январь 2026 и позже) - полная поддержка
• TypeScript 6.0 Beta (февраль 2026 и позже) - полная поддержка
• Safari - частичная поддержка в Technology Preview
• Node.js 26 - планируется полная поддержка

Для проверки поддержки в коде используйте простую проверку:

const hasTemporalSupport = typeof globalThis.Temporal !== "undefined";

if (hasTemporalSupport) {
  // Используйте Temporal
} else {
  // Fallback на Date или полифилл
}

Эффективная стратегия внедрения - гибридный подход. Используйте Temporal для внутренней логики, где вы контролируете окружение, но сохраняйте Date для граней API, где общаетесь с внешним кодом. Это даёт вам преимущества нового API без необходимости срочно переписывать всё.

Что нужно помнить о совместимости:

• Не все браузеры поддерживают Temporal одинаково - проверьте целевую аудиторию
• Safari пока находится в стадии Technology Preview - подождите финального релиза
• Для production проверяйте наличие Temporal перед использованием
• Используйте полифилл для старых окружений, если критична совместимость
• TypeScript уже готов работать с Temporal начиная с версии 6.0

Что это означает для экосистемы

Выход Temporal в стандарт - это больше, чем просто новая библиотека. Это означает, что библиотеки вроде Moment.js и date-fns теперь имеют встроенную конкуренцию из самого JavaScript. Moment.js уже устарел, а date-fns остаётся полезным для дополнительных функций, но нативный API будет быстрее, легче и надёжнее.

Для разработчиков это означает несколько важных сдвигов. Во-первых, вы наконец можете писать код с датами, не боясь ошибок с таймзонами. Во-вторых, благодаря immutability код становится более безопасным и понятным для анализа. В-третьих, вся команда может положиться на один стандартный способ работы с временем, без нужды обучать новичков хитростям Date.

Для типизированного кода это особенно важно. TypeScript теперь может различить PlainDate, PlainTime и ZonedDateTime, предотвращая смешение даты и времени на уровне типов. Это предотвратит целый класс ошибок, которые раньше находились только при тестировании.

Важные следствия внедрения Temporal:

• Конец эпохи Moment.js - нативный API стал стандартом
• Типизация дат - TypeScript может различить разные временные типы
• Предсказуемость - мутации исключены, поведение определено
• Интернационализация - встроенная поддержка разных календарей
• Производительность - нативная реализация быстрее любой библиотеки

Практические советы по миграции

Если вы управляете крупным проектом, миграция на Temporal требует продуманного подхода. Вам не нужно переписывать всё за один день - можно делать это постепенно.

Начните с новых функций. Когда вы пишете новый модуль, используйте Temporal вместо Date. Так вы постепенно наращиваете опыт и не рискуете сломать существующий код. Для граней API, где вы принимаете Date от пользователей, создайте функции-конвертеры, которые переводят Date в Temporal и обратно.

Когда вы переходите существующий код, начните с модулей, которые работают с датами критически - например, с обработкой встреч, расписаний или отчётов по времени. Именно здесь Date доставляет больше всего проблем.

Рекомендации по миграции:

• Начните с новых функций - используйте Temporal в новом коде
• Переходите модуль за модулем - не переписывайте всё сразу
• Тестируйте DST - если работаете с таймзонами, проверьте переводы часов
• Обновите зависимости - убедитесь, что TypeScript и другие инструменты поддерживают Temporal
• Документируйте - объясните команде, почему вы переходите на новый API
• Используйте полифилл - для браузеров, где Temporal недоступен

Что дальше и на что обратить внимание

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

Одно из главных предостережений - не все окружения поддерживают Temporal одинаково. Safari пока находится в стадии Technology Preview, а это значит, что если ваша целевая аудитория активно использует Safari, вам нужен полифилл или резервный план. Проверьте статистику браузеров вашего проекта перед внедрением.

Другой аспект, который стоит учитывать - производительность. Хотя Temporal оптимизирован и должен работать быстро, в некоторых сценариях с массовой обработкой дат старый Date может быть быстрее. Меряйте на своих данных, если это критично для вас.