Форматирование даты и переносимость часовых поясов

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

ECMA-402 определяет международные API, MDN описывает Intl.DateTimeFormat, а W3C объясняет различие даты и часового пояса. Эти источники помогают построить переносимый слой представления, но не обещают одинаковые знаки препинания или сокращения во всех средах.

Сначала определите значение

Момент 2026-01-01T01:30:00Z означает одну точку времени везде; Z обозначает UTC. События, аудиты, платежи и доставка сообщений обычно требуют момента, потому что читатели могут находиться в разных местах.

Календарная дата имеет другое значение. День рождения, заезд в отель или расчетный период могут обозначать день бизнеса, а не полночь универсального времени. Преобразование в момент и последующее применение зоны читателя может перенести дату на соседний день. Если время не является частью предметной области, храните дату без времени.

Местное время площадки, например «09:00 в Берлине», требует местных полей и идентификатора IANA. Это не то же самое, что «09:00 в зоне читателя». Продукт должен выбрать зону площадки, участника или отчета. Опишите контракт ввода и не позволяйте анализатору JavaScript угадывать смысл неоднозначной строки.

Явно выберите политику зоны

timeZone: 'UTC' подходит стабильному отчету, а timeZone: 'America/New_York' показывает гражданское время региона. Без опции среда обычно использует свою зону по умолчанию. Это может быть удобно для личных часов, но не для отчета с фиксированным обещанием. Источником зоны должна быть видимая настройка пользователя, место события или правило организации. Предпочтение браузера является подсказкой, а не доказательством места проживания или личности.

Показывайте название зоны, смещение или понятную подпись, если сравнение важно. Для повторяющихся событий храните идентификатор IANA: одно фиксированное смещение не описывает будущий переход на летнее время. Выбирайте представление по смыслу данных и документируйте преобразования.

Используйте ECMA-402 без жесткой пунктуации

Форматировщик получает локаль, параметры и зону. Приложение определяет значимые поля, браузер определяет порядок, цифры и знаки. Язык и зона независимы: русские подписи могут показывать встречу в Торонто, а французские - отчет UTC. formatToParts() помогает семантической верстке, но порядок частей нельзя считать одинаковым для всех языков.

Не сравнивайте одну точную строку во всех версиях браузера. Региональные данные меняются. Проверяйте значение, параметры, день и час, понятные пользователю. Машинные данные, базы и подписи должны иметь стабильные контракты; локализованную строку нельзя надежно разобрать обратно в отметку времени.

Учитывайте летнее время и границы календаря

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

Високосные дни и длина месяца требуют той же осторожности. Добавление 24 часов к моменту не всегда означает следующий гражданский день. Решите, следует ли повторение прошедшей длительности или календарной арифметике, и только потом форматируйте результат.

Подготовьте переносимый резервный путь

Проверяйте используемые возможности. Если опция недоступна, применяйте простую конфигурацию, значение сервера или структурированную дату с явной подписью UTC. Резервный путь обязан сохранить значение и контекст: нельзя молча заменить время площадки временем читателя или убрать зону из срока.

Сопоставляйте запрошенные языковые теги со списком поддерживаемых языков. Отсутствующий региональный вариант может перейти к базовому языку, не меняя политики зоны. Обновление системы способно изменить будущие правила: храните исходный момент и идентификатор зоны. Сервер и браузер должны использовать одно структурированное значение и объявленную зону, чтобы избежать скачка от UTC к местному времени при загрузке.

Сделайте отображение доступным

Укажите назначение даты: срок, отправление, продление или измерение. Добавьте зону, когда возможна путаница. Используйте семантические подписи, масштабируемый текст и перенос длинных названий; проверьте экранный диктор и письма справа налево. При смене языка или зоны сохраняйте форму и личность события и объясняйте, меняется ли только представление.

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

Проверяйте реальные задачи

Создайте фикстуры момента, даты без времени, встречи площадки и повторения. Для 2026-01-01T01:30:00Z UTC дает 1 января 2026 01:30, а America/New_York - 31 декабря 2025 20:30. Оба результата должны означать один момент и показывать контекст зоны; пробелы и знаки могут отличаться. Дата 2026-01-01 должна оставаться 1 января в любой зоне.

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

Переносимость дат - это контракт: структурированные значения задают смысл, явная политика зоны задает контекст, а ECMA-402 создает локализованный вид. Обновление браузера может изменить пунктуацию, не меняя событие и сохраненные данные.

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

Письмо или уведомление со сроком должно включать дату, время и зону, поскольку его могут читать вне исходного интерфейса.

Миграция старых строк требует решения предметной области: превращение даты без времени в UTC может изменить видимый день.

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

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

Макет должен оставлять место длинным названиям месяцев и разрешать перенос подписи зоны.

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

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

Смена языка меняет вид, но не должна конвертировать валюту или менять сохраненный момент.

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

Повторяющееся календарное событие требует правила для дня, которого нет после смены месяца.

Повторяющийся местный час нужно различать моментом или смещением до подтверждения встречи.

Диагностика поддержки должна содержать только данные для воспроизведения, а не общий профиль браузера.

Проверка доступности должна озвучивать полную дату и зону, даже если на экране используется сокращение.

Резервный путь сохраняет дату и объясняет контекст на поддерживаемом языке.

Сокращения зон могут измениться между версиями; стабильными ссылками остаются идентификатор IANA и момент.

Продукт должен решить, редактирует ли пользователь местное время или выбирает уже подтвержденный момент.

Эти правила превращают типографическую разницу в безопасную вариацию, а не в потерю смысла.

Источники

• ECMA-402
• MDN: Intl.DateTimeFormat
• W3C Internationalization: часовые пояса
• WHATWG HTML: Web application APIs

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