Temporal API достигает stage 4: конец эры Date в JavaScript

hannadev

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

Дата в JavaScript всегда была болезненной темой. Старый Date API создаёт неимущественные объекты, не поддерживает таймзоны, не умеет работать с интервалами и длительностями. Temporal меняет всё это с корня и делает работу со временем наконец удобной и предсказуемой.

Почему Date — это кошмар для разработчика

Date объект в JavaScript — это пережиток прошлого, который несёт на себе все грехи своего возраста. Когда он создавался, никто не думал об удобстве использования. Результат: изменяемые объекты, которые вызывают побочные эффекты, поддержка таймзон на уровне «знаете, давайте просто конвертировать в UTC и забудем о проблеме». Это привело к бесчисленным ошибкам в production’е.

Минут пять программирования с Date — и уже ясно, почему люди устанавливают огромные библиотеки вроде moment.js или day.js. Нужно работать с локальным временем? Проблемы. Нужна просто дата без времени? Ещё больше проблем. Нужен интервал между двумя датами? Приходится городить костыли из вычитания миллисекунд.

Вот что делает Date неудобным:

Изменяемость - любой вызов setter’а меняет объект прямо в месте, создавая баги с побочными эффектами
Отсутствие поддержки таймзон - встроенная работа с часовыми поясами практически невозможна
Нет типов для разных сценариев - нельзя просто работать с датой без времени, без костылей
Невозможно работать с длительностями - нет встроенного типа для интервалов между моментами времени
Непредсказуемое поведение - на разных платформах и браузерах парсинг строк может давать разные результаты
Невероятно раздутый API - методы вроде getDay() и getDate() создают путаницу своими названиями

Что такое Temporal и как он это меняет

Temporal — это не просто один новый класс, а целое namespace с набором типов для управления временем. Это как модуль Intl, который уже есть в браузерах, но только для дат и времени. Философия простая: построить новое с нуля вместо того, чтобы пытаться спасти старое.

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

Temporal работает со стандартами: таймзоны берутся из IANA Time Zone Database (которая уже есть в браузерах), форматы строк основаны на RFC 9557, длительности — на ISO-8601. Браузеры уже загружают метаданные о смене часовых поясов, поэтому разработчику не нужно доставлять эту информацию отдельно.

Основные типы Temporal:

Temporal.Instant - конкретный момент времени в UTC, как точка на оси времени
Temporal.ZonedDateTime - дата и время с привязкой к определённой таймзоне
Temporal.PlainDate - просто дата без времени, без таймзоны, без лишнего
Temporal.PlainTime - просто время суток, без даты и таймзоны
Temporal.Duration - интервал между двумя моментами, поддерживает любые единицы
Temporal.PlainDateTime - дата и время, но без таймзоны

Практические примеры: как это выглядит

Сравнить старый способ и новый - лучший способ понять выигрыш. Возьмём простую задачу: создать дату и вывести её красиво.

Старый способ с Date:

let usingDate = new Date('2025-04-03');
console.log(usingDate);
// Wed Apr 02 2025 21:00:00 GMT-0300 (Chile Summer Time)
// Что-то не то... это уже вчерашний день из-за таймзоны!

Новый способ с Temporal:

let usingTemporal = Temporal.PlainDate.from('2025-04-03');
console.log(usingTemporal.toString());
// 2025-04-03
// Ровно то, что мы просили, без сюрпризов

Теперь посложнее: нужно работать с конкретным временем в определённой таймзоне. Например, концерт начинается 31 января 2026 в 18:00 по московскому времени.

let concertTime = Temporal.ZonedDateTime.from('2026-01-31T18:00:00[Europe/Moscow]');
console.log(concertTime.toString());
// 2026-01-31T18:00:00+03:00[Europe/Moscow]

Добавить к этому времени сутки?

let nextDay = concertTime.add({days: 1});
console.log(nextDay.toString());
// 2026-02-01T18:00:00+03:00[Europe/Moscow]

Преобразовать в другую таймзону (например, узнать, во сколько это будет в Нью-Йорке)?

let newyorkTime = concertTime.withTimeZone('America/New_York');
console.log(newyorkTime.toString());
// 2026-01-31T10:00:00-05:00[America/New_York]

Видите разницу? С Temporal код читается как обычное описание: добавь день, переведи в другую таймзону. С Date пришлось бы мучиться с миллисекундами, вычитаниями и подвохами парсинга.

Ещё один пример - работа с интервалами. Нужно узнать, сколько дней между двумя датами?

let start = Temporal.PlainDate.from('2026-01-15');
let end = Temporal.PlainDate.from('2026-03-10');
let duration = start.until(end);
console.log(duration.toString());
// P55D (55 дней)

Это встроено в язык, не нужна никакая библиотека.

Статус Stage 4 и что это значит

Temporal был в Stage 3 долгое время. На этой стадии спецификация практически закончена, просмотрена, и маловероятны значительные изменения. Но для попадания в Stage 4 нужно кое-что серьёзное: две независимые, совместимые реализации в браузерах, которые проходят все тесты.

Первым Temporal поддержал Firefox. Deno включил его за флагом. Chrome разработчики активно работают над реализацией. Но для официального Stage 4 нужно ждать, пока как минимум два браузера полностью его реализуют и замерзят реализацию.

Это не означает, что можно начинать использовать прямо сейчас везде. Но для тех, кто работает с полифилами или готов использовать на backend’е (например, в Node.js), это уже доступно. На production’е в браузерах лучше подождать ещё немного.

Что произойдёт дальше:

Firefox уже имеет поддержку, это даёт нам одну реализацию
Chrome находится в процессе разработки, это может дать вторую реализацию
Safari и другие браузеры будут следить за ситуацией
После двух реализаций будет голосование в TC39 и переход в Stage 4
Затем полная поддержка во всех браузерах (это может занять год или два)

Как использовать Temporal уже сейчас

Дожидаться полной поддержки браузерами — это одно дело. Но есть несколько способов уже сегодня начать работу с Temporal.

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

TypeScript - если вы пишете на TypeScript, уже можно подключить типы для Temporal и начать кодить. Во время runtime’а код будет работать медленнее на старых браузерах, но хотя бы вы проверите типы.

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

Deno - если вы используете Deno вместо Node.js, там Temporal поддерживается за флагом. Это отличный способ попробовать его в боевых условиях.

Опции для внедрения:

Использовать полифил для браузеров и переписать старый код постепенно
Для новых проектов начать писать с Temporal и полифилом с дня первого
На backend’е переходить без ограничений, если платформа поддерживает
Писать абстракцию над временем, которая легко переключается между Date и Temporal

Переход с Date на Temporal: реальные выгоды

Одна из главных проблем Date — это хрупкость. Код выглядит одинаково везде, но на разных платформах может вести себя по-разному. На одном сервере в UTC, на другом в локальной таймзоне. Такие ошибки находятся месяцами.

Temporal решает это явностью. Если вам нужна таймзона, вы обязаны её указать. Если нужна просто дата, вы используете PlainDate, а не Date с хаком. Компилятор (или IDE) сразу скажет, что что-то не так.

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

Третья выгода — встроенная работа с интервалами и конвертациями. Не нужно подтаскивать external библиотеки для простых операций. Всё есть в языке.

Четвёртая — стандартизация на уровне браузера. Метаданные о таймзонах уже загружены. Разработчику не нужно поставлять свою базу данных часовых поясов. Браузер это знает.

Выигрыши при переходе:

Код становится читаемым - операции с временем выглядят как английский язык
Ошибки сокращаются - статическая типизация и явность предотвращают целый класс багов
Производительность улучшается - не нужно загружать тяжёлые полифилы и библиотеки
Поддержка упрощается - новый разработчик быстрее разберётся в коде
Кроссбраузерность гарантирована - поведение одинаковое везде

Интеграция с остальной платформой

Temporal не живёт отдельно. Он хорошо интегрируется с тем, что уже есть в JavaScript.

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

JSON сериализация - Temporal объекты могут быть сконвертированы в строку через toJSON(). Это даёт стандартный формат RFC 9557, который легко парсить и передавать по сети.

Календари - Temporal поддерживает разные системы календарей. Не только привычный gregorian, но и islamic, hebrew, chinese и другие. Это встроено, не нужны костыли.

Сравнение и сортировка - объекты Temporal можно сравнивать через стандартные операторы. Можно сортировать массивы дат как обычно.

Что остаётся за пределами

Temporal это не панацея и не может решить все задачи, связанные со временем. Есть вещи, которые остаются вне его сферы.

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

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

Ищите, на что обратить внимание при миграции: старайтесь не смешивать Date и Temporal в одном коде, выбирайте один подход и придерживайтесь его. Это упростит тесты и поддержку.