Кратко

  • В исходном RFC 3339 -00:00 означал известный момент UTC при неизвестном локальном смещении, а Z и +00:00 — предпочтительную ссылку на UTC. RFC 9557 позже перенёс смысл неизвестного смещения на Z, не изменив +00:00.
  • Равные нормализованные моменты не равны как доказательства. Исходные байты, профиль толкования, происхождение смещения, дробная точность, состояние часов, таблица високосных секунд, захват и результат приложения требуют отдельных квитанций.

Новый интерпретатор открыл старый архив

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

В первоначальной секции 4.3 RFC 3339 форма -00:00 сообщала: время в UTC известно, смещение к местному времени — нет. Z и +00:00 подразумевали, что UTC служит предпочтительной точкой отсчёта. Момент мог совпадать, но заявление о происхождении различалось.

Конвенция пришла из электронной почты. RFC 2822 и RFC 5322 используют -0000 для Universal Time без информации о локальной зоне системы-источника. Строка отвечает на вопрос «когда», но честно не отвечает на вопрос о локальном контексте.

RFC 9557 изменил смысл ради совместимости

Отрицательный ноль плохо взаимодействовал с окружающими стандартами. ISO 8601:2000 и более поздние редакции не разрешали -00:00, а реализации нередко использовали Z для неизвестного локального смещения. RFC 9557 привёл RFC 3339 в соответствие с этой практикой.

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

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

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

Числовое смещение не было именем зоны

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

Несколько зон могут иметь одно смещение сегодня и разные переходы завтра. Формат TZif из RFC 8536 отдельно хранит переходы, типы местного времени, обозначения и поправки високосных секунд. В простом смещении этих данных нет.

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

Неизвестное смещение не было плавающим временем

В RFC 3339 неизвестен не момент. Он определён в UTC; отсутствует только связь с местным временем. Неквалифицированное локальное время документ счёл неприемлемым для общего обмена, поскольку вне своей зоны оно почти наверняка будет понято неверно.

RFC 5545 намеренно описывает другое — floating time. Событие «в 11 часов, где бы вы ни находились» сохраняет показание циферблата, но может наступить в разных реальных моментах для участников.

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

Строковая сортировка действовала в узких условиях

RFC 3339 отметил удобство текстовой сортировки, но поставил условия: одинаковые зоны, одинаковая запись зоны и равное число дробных цифр. Только в этом коридоре лексический порядок становится временным.

Разные смещения, смесь Z с +00:00 или разные длины дроби выходят за гарантию. Базовая ABNF допускает строчные t и z, хотя прикладной протокол может требовать прописные. Проверенные errata исправляют редакционные и приложенческие детали; собранную в Приложении A грамматику ISO нельзя считать тем же самым, что профиль Секции 5.6.

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

Число знаков не подтверждало точность часов

Дробь секунды была единственной редко используемой опцией RFC 3339. Она предназначалась для строгого порядка или особой точности и могла иметь один или больше знаков. Длина описывает запись, а не достоверность часов.

Несинхронизированное устройство способно печатать наносекунды; прослеживаемый источник — только целые секунды. RFC 5905 отдельно описывает NTP, страты, смещения и ошибки. Строка времени не является отчётом о синхронизации.

Разделяйте заявленную точность, разрешение, источник, последнюю синхронизацию, неопределённость и путь захвата. Дополнение нулями не улучшает измерение.

Шестидесятая секунда требовала внешнего расписания

RFC 3339 разрешает 60 на границе месяца с положительной високосной секундой и допускает максимум 58 при возможном удалении секунды. Грамматика не знает, была ли поправка назначена на указанную дату.

RFC 8536 показывает поправки и переходы в версионируемых данных, RFC 5905 — отдельное состояние часов. Принять 23:59:60 означает подтвердить синтаксис, но не календарь.

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

Метка времени не удостоверяла событие

RFC 3339 стандартизировал форму, а не доверие. Он не доказывает автора, момент добавления поля, охват подписи или исполнение действия. Метка рядом с подписью может быть вне неё; время получения отличается от захвата; неверные часы создают корректную будущую дату.

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

История RFC 3339 делает границу наглядной: момент остался тем же, а стандартизированное толкование записи изменилось. Хронология нуждается в нормализации; ответственность — ещё и в происхождении.

Источники