rfc3339

https://datatracker.ietf.org/doc/html/rfc3339

Все даты и время принимаются как происходящие в текущей эре (между 0000AD и 9999AD)

• B.C. - before Christ
• A.D. - anno domini, or "in the year of our lord"

Все время выражается с указанием смещения относительно UTC
Это исключает перепуточки из-за принятия локальных административных решений типа "летнее зимнее время"

"Z" - Суффикс прикладываемый ко времени, обозначающий UTC оффсет от 00:00
Произносится как "Zulu"

Zulu time, больше известное как "GMT" (Greenwich Mean Time) это время на нулевом меридиане

Следующие требования направлены на проблему неоднозначности при обозначения года двумя цифрами:

• Интернет протоколы должны генерить четырех цифровые года
• Использование 2-х цифровых годов отменено. Если был получен двух цифровой год, то он должен быть принят как валидный только в том случае если его интерпретация не станет причиной ошибки в работе протокола
• Некоторые древние программы могут представлять годы после 1999 как трехзначные

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

Разница между локальным временем и UTC высчитвается как "local time minus UTC"
Соответственно UTC может быть высчитан как "local time minus offset"

Например: 18:50:00-04:00 - локальное врeмя и отрицательный оффсет -> 22:50:00Z

Если известно время в UTC, но незвестен оффсет, то такое время может быть представлено с оффсетом "-00:00"
Это не то же самое что и оффсет "Z" или "+00:00", который подразумевает что UTC и есть желаемое время

Если компоненты даты расположены от наименее точного к наиболее точному, то достигается одно очень удобное свойство
Если таймзоны одинаковые и представлены например как "Z" или "+00:00", то даты можно отсоритровать как строки

Человекочитаемость доказала свою важность в интернет протоколах. Человекочитаемость протоколов значительно сокращает стоимость дебагинга, но с другой стороны она добавляет проблемы совместимости
Например дата "10/11/1996" абсолютно непригодна для глобального обмена, потому что она будет интерпретировать по разному в разных странах

Так как нет формата дат легкочитаемого во всех странах, интернет клиенты должны трансформировать дату в локальный формат

date-fullyear   = 4DIGIT
date-month      = 2DIGIT  ; 01-12
date-mday       = 2DIGIT  ; 01-28, 01-29, 01-30, 01-31 based on
                             ; month/year
time-hour       = 2DIGIT  ; 00-23
time-minute     = 2DIGIT  ; 00-59
time-second     = 2DIGIT  ; 00-58, 00-59, 00-60 based on leap second
                             ; rules
time-secfrac    = "." 1*DIGIT
time-numoffset  = ("+" / "-") time-hour ":" time-minute
time-offset     = "Z" / time-numoffset

partial-time    = time-hour ":" time-minute ":" time-second
                     [time-secfrac]
full-date       = date-fullyear "-" date-month "-" date-mday
full-time       = partial-time time-offset

date-time       = full-date "T" full-time

Символы "T" и "Z" должны быть прописными

Секунда может быть равна 60 или 58 в определенные моменты (leap second, високосная секунда)
Этот момент не может быть предсказан далеко в будущее. О наступлении leap second объявляет за пару недель служба IERS

Примеры:

• UTC с дробной секундой

  1985-04-12T23:20:50.52Z
  

• 1996-12-19T16:39:57-08:00 - local time; -08:00 - offset; 1996-12-20T00:39:57Z - UTC

  1996-12-19T16:39:57-08:00
  

• leap second with offset

  1990-12-31T15:59:60-08:00