Temporal API на стадии 4: полноценная замена Date на Rust в ECMAScript 2026

hannadev

Temporal API наконец-то выходит на стадию 4 в TC39 и становится полноценной частью ECMAScript 2026. Это современный инструмент для работы с датами и временем, который решает все проблемы legacy-объекта Date: мутабельность, кривой парсинг, хаос с часовыми поясами. Теперь разработчики получат immutable типы, точную обработку зон и календарей - без багов и сюрпризов.

Зачем это нужно? Date десятилетиями мучил всех: один неверный вызов метода - и данные слетают, парсер путает форматы, а переходы на летнее время ломают логику. Temporal меняет правила игры, предлагая предсказуемое API. С ним проще строить приложения с международной поддержкой, от аналитики до планировщиков.

Почему Date пора на пенсию

Объект Date в JavaScript - это relic из 90-х. Он мутирует состояние при простых операциях, вроде добавления часов, что приводит к ошибкам в многопоточных сценариях или при параллельных вычислениях. Парсинг строк работает непредсказуемо: ‘01/02/2026’ может стать 1 февраля или 2 января в зависимости от локали. Часовые пояса? Только UTC и локальный, без нормальной поддержки IANA-зон вроде ‘Europe/Moscow’.

Temporal решает это радикально. Все объекты - неизменяемые, операции возвращают новые экземпляры. Парсер строг: только ISO-8601 без неоднозначностей. Поддержка всех зон времени и календарей из коробки, включая японский или исламский. Реализация на Rust (через temporal_rs) обеспечивает скорость и безопасность даже в V8.

Плюс, Temporal уже работает в Chrome 144 и Firefox 139, Safari догоняет. К марту 2026 на встрече TC39 в Нью-Йорке ожидают апрув Stage 4 - и вот оно, стандарт ES2026.

Immutable операции: const tomorrow = today.add({ days: 1 }) - оригинал не меняется.
Точные зоны: Temporal.ZonedDateTime.from('2026-03-10T12:00[Europe/Moscow]').
Безопасный парсинг: Никаких сюрпризов с ‘MM/DD’ vs ‘DD/MM’.
Rust-бэкенд: Общая библиотека для V8, Boa и Kiesel - единое поведение.

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

Temporal - это не один класс, а набор специализированных типов под задачи. Temporal.PlainDate для дат без времени, Temporal.PlainTime для времени без даты, Temporal.ZonedDateTime для полного datetime с зоной. Каждый тип фокусируется на своей роли, избегая перегрузки как в Date.

Пример: нужно посчитать разницу между встречами в разных зонах. С Date пришлось бы вручную конвертировать в миллисекунды, рискуя ошибками DST. В Temporal: zoned1.until(zoned2) вернет Temporal.Duration с днями, часами, минутами - точно и без мутаций. Арифметика работает с учетом календарей: добавь год к 28 февраля в високосный - получишь правильный день.

Это упрощает код в библиотеках вроде scheduling или analytics. Форматирование через toLocaleString интегрируется с Intl API, поддерживая локали.

Тип	Описание	Пример использования
PlainDate	Дата без времени	`Temporal.PlainDate.from('2026-03-10')`
PlainTime	Время без даты	`Temporal.PlainTime.from('12:00:00')`
ZonedDateTime	Дата-время с зоной	`Temporal.Now.zonedDateTimeISO('UTC')`
Instant	Момент в UTC	`Temporal.Instant.from('2026-03-10T12:00:00Z')`
Duration	Интервал	`date1.until(date2)`

Temporal.Instant - для точных моментов, игнорирует календари.
Temporal.Calendar - абстракция для не-григорианских систем.
Нюанс: Диапазон дат от -271821 до +275760 года - хватит на века.

Сравнение Date и Temporal на примерах

Возьмем типичную задачу: парсим строку, добавляем час, выводим в локальной зоне. С Date: new Date(isoString) может сдвинуть время из-за локали, setHours мутирует объект. Результат? Баги в проде.

Temporal чище: Temporal.Instant.from(isoString).toZonedDateTimeISO('Africa/Johannesburg') - и вуаля, точный вывод с оффсетом. Арифметика: zonedDateTime.add({ hours: 1 }) создает новый объект, без побочек.

В production это спасает от edge-кейсов вроде DST или високосных лет. Библиотеки начнут мигрировать: scheduling-аппы выиграют от Duration.

// Date - старый способ
new Date('2026-03-20T23:00:00Z').toString(); // Sat Mar 21 2026 01:00:00 GMT+0200

// Temporal - новый
Temporal.Instant.from('2026-03-20T23:00:00Z')
  .toZonedDateTimeISO('Africa/Johannesburg')
  .toString({ timeZoneName: 'never' }); // 2026-03-21T01:00:00+02:00

Преимущества Temporal: Immutable, зоны, календари, надежный парсер.
Минусы Date: Мутации, неоднозначный парсинг, слабые зоны.
Важно: Date остается для legacy, но новый код - на Temporal.

Что скрывают лимиты Temporal

Несмотря на мощь, есть рамки. Диапазон ±10^8 дней от эпохи - для большинства хватит, но астрономы подумают. Нет наносекунд в PlainDate, только в Instant. Safari еще тестирует, так что полифиллы нужны для full cross-browser.

TC39 учел фидбек: Stage 3 дал стабильность, Stage 4 - финал. Rust-имплементация ускоряет движки, минимизируя расхождения. В ES2026 Temporal - стандарт, но миграция библиотек займет время: смотрите на GitHub-репо для обновлений.

Подумайте о календарях: Temporal открывает двери для азиатских или религиозных систем без хаков. А как это повлияет на Node.js или Deno? Здесь простор для экспериментов, пока экосистема адаптируется.