RFC 3339 Date and Time on the Internet: Timestamps

Network Working Group                                           G. Klyne
Request for Comments: 3339                        Clearswift Corporation
Category: Standards Track                                      C. Newman
                                                        Sun Microsystems
                                                               July 2002

Date and Time on the Internet: Timestamps

Метки даты и времени в Internet

PDF

Статус документа

В этом документе описан проект стандартного протокола Internet, предложенного сообществу Internet, документ служит приглашением к дискуссии в целях развития предложенного протокола. Текущее состояние стандартизации протокола можно узнать из документа Internet Official Protocol Standards (STD 1). Документ может распространяться свободно.

Авторские права

Copyright (C) The Internet Society (2002). All Rights Reserved.

Аннотация

Этот документ задаёт формат даты и времени для использования в протоколах Internet, который является профилем стандарта ISO 8601 для представления даты и времени по григорианскому календарю.

1. Введение

Форматы дат и времени вызывают много путаницы и проблем совместимости в Internet. В этом документе рассматриваются многие из таких проблем и приводятся рекомендации по улучшению согласованности и совместимости при использовании дат и времени в протоколах Internet.

Документ включает профиль Internet для использования стандарта ISO 8601 [ISO8601] при представлении дат и времени по григорианскому календарю.

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

• Предполагается, что все даты и время относятся к «текущей эре» между годами 0000 и 9999.

• Время указывается с учётом смещения (offset) относительно универсального скоординированного времени (Coordinated Universal Time или UTC). Это отличается от некоторых применений в приложениях планирования, где местное время и местоположение могут быть известны, но фактическая связь с UTC может зависеть от неизвестных или нераскрываемых действий политиков и администраторов. Время UTC, соответствующее 17:00 23 марта 2005 г. в Нью-Йорке, может зависеть от административного решения по использованию летнего времени (daylight savings time). Эта спецификация не рассматривает такие вопросы.

• Временные метки могут указывать время введения UTC. Такие метки указываются универсальным временем, применявшимся в соответствующий период.

• Дата и время указывают момент времени. Описание интервалов или периодов не рассматривается здесь.

2. Определения

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не следует (SHALL NOT), следует (SHOULD), не нужно (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с [RFC2119].

UTC

Универсальное (всемирное) скоординированное время, поддерживаемое Международным бюро мер и весов (Bureau International des Poids et Mesures или BIPM).

second – секунда

Базовая единица измерения времени в системе СИ (International System of Units). Определена как продолжительность 9192631770 колебаний, поглощаемых или излучаемых атомами цезия-133 в основном состоянии, не нарушаемом внешними полями.

minute – минута

Период времени в 60 секунд. В параграфе 5.7 и Приложении D описан учёт високосных секунд в минутах.

hour – час

Период времени в 60 минут.

day – день (сутки)

Период времени в 24 часа.

leap year – високосный год

В григорианском календаре – год, включающий 366 дней. Високосными являются годы, кратные четырём, но не кратные 100, при этом годы, кратный 400, являются високосными.

ABNF

Расширенная форма Бэкуса-Наура – формат представления разрешённых строк в протоколе или языке, заданный в [ABNF].

Email Date/Time Format

Формат дат и времени, используемый в почте Internet в соответствии с RFC 2822 [IMAIL-UPDATE].

Internet Date/Time Format

Формат дат, заданный в разделе 5 этого документа.

Timestamp – метка времени

В этом документе указывает однозначное представление некого момента времени.

Z

Суффикс, который применительно к времени означает нулевое смещение от UTC (00:00). Часто говорят Zulu из фонетического алфавита ICAO, где это представляет букву Z.

Дополнительные сведения о шкалах времени приведены в Приложении E к [NTP], разделе 3 в [ISO8601] и соответствующих документах ITU [ITU-R-TF].

3. Две цифры года

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

• Протоколы Internet должны указывать год 4 цифрами.

• Использовать 2 цифры для указания года не рекомендуется. При получении такого значения эго следует воспринимать лишь в тех случаях, когда некорректная интерпретация не приведёт к отказу протокола или обработки (например, при использовании для записи системного журнала или при отслеживании).

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

• Возможно, что программа использующая для года две цифры, будет представлять даты после 1999 г. как :0, :1, … :9, ;0, … Это будет происходить, если программа просто вычитает из года значение 1900 и и прибавляет десятилетие к символу US-ASCII 0. Программам, желающим надёжно обрабатывать такие даты, следует проверять нечисловые десятилетия и интерпретировать их должным образом.

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

4. Местное время

4.1. Универсальное скоординированное время (UTC)

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

4.2. Часовые пояса

Смещение местного времени относительно UTC часто даёт полезные сведения. Например, в электронной почте (RFC2822, [IMAIL-UPDATE]) смещение обеспечивает полезную эвристику для определения вероятности быстрого ответа. Попытки указывать смещение строками букв приводили к плохой совместимости [IMAIL], [HOST-REQ]. В результате документ RFC2822 [IMAIL-UPDATE] сделал цифровое смещение обязательным.

Смещение определяется вычитанием UTC из местного времени, поэтому эквивалент UTC можно получить вычитание смещения из местного времени. Например, 18:50:00-04:00 указывает то же время, что и 22:50:00Z. Здесь используется отрицательное смещение, обрабатываемое с учётом знака.

Примечание. В соответствии с ISO 8601 численное смещение представляет лишь часовые пояса, отличающиеся от UTC на целое число минут. Однако многие реальные часовые пояса отличаются от UTC нецелым числом минут. Для точного представления таких временных меток приложения должны преобразовывать их в представляемый часовой пояс.

4.3. Преобразование неизвестных часовых поясов

Если известно время UTC, но неизвестно смещение локального времени, его можно представить в форме -00:00. Это семантически отличается от Z и +00:00, подразумевающих, что UTC является предпочтительным для указания времени. В RFC2822 [IMAIL-UPDATE] описано аналогичное соглашение для электронной почты.

4.4. Неполное местное время

Множество устройств, подключённых к Internet используют часы с местным временем и не знают о UTC. Хотя в Internet существует традиция учитывать реальность при разработке спецификаций, это не должно препятствовать совместимости. Поскольку интерпретация неполного указания местного времени (без часового пояса) не будет работать в 23/24 планеты, проблемы совместимости из-за неполного указания местного времени считаются неприемлемыми для Internet. Системы с локальным временем, не знающие смещения от UTC и зависящие от синхронизации часов с другими системами Internet, должны применять механизм, обеспечивающий корректную синхронизацию с UTC. Некоторые из подходящих механизмов указаны ниже.

• Использование протокола сетевого времени (Network Time Protocol) [NTP] для получения времени UTC.

• Использование другого хоста в том же часовом поясе в качестве шлюза в Internet. Этот хост должен корректировать неполное местное время, передаваемое другим хостам.

• Запрос у пользователя местного часового пояса и настроек сезонного времени.

5. Формат даты и времени

В этом разделе рассматриваются желаемые свойств дат и времени и задан профиль ISO 8601 для протоколов Internet.

5.1. Упорядочение

Если компоненты даты и времени упорядочены от менее точных к более точным, это обеспечивает полезность формата. Предположим, что часовые пояса дат и времени совпадают (например, UTC), выражены однотипными строками (например, везде Z или +00:00), а для времени используется одинаковой число цифр в дробной части секунд, значения даты и времени можно сортировать как обычные строки (например, с помощью функции strcmp() языка C) и в результате получать упорядоченные по времени последовательности. Если формат допускает необязательные знаки препинания или пробелы, это упорядочение может не работать¹.

5.2. Читаемость для человека

Удобочитаемость для человека оказалась важным свойством протоколов Internet. Понятные человеку протоколы существенно сокращают время отладки, поскольку в качестве клиента часто применяется telnet, а сетевые анализаторы не требуется менять для понимания протоколов. С другой стороны, читаемость для человека иногда ведёт к проблемам взаимодействия. Например, даты в формате 10/11/1996 совершенно не подходят для глобального обмена, поскольку интерпретация в разных странах отличается. Кроме того, формат дат из [IMAIL] ведёт к проблемам совместимости, когда людт предполагают, что разрешены любые строки текста, переводят трехбуквенные сокращения на другие языки или заменяют форматом, который проще создать (например, форматом, применяемым в функции C ctime). По этим причинам нужно соблюдать баланс между удобочитаемостью и совместимостью.

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

5.3. Редко применяемые опции

Формат с редко применяемыми опциями может вызывать проблемы совместимости. Это связано с тем, что такие опции с меньшей вероятностью будут применяться в alpha- или beta-тестировании, поэтому вероятность обнаружения связанных с ними ошибок снижается. Такие опции опции следует опускать или делать обязательными, если возможно.

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

5.4. Избыточные сведения

Если формат даты-времени включает избыточные сведения, возникает вероятность их несогласованности. Например, включение дня недели в формат создаёт возможность путаницы, когда день недели неверный при корректной дате или наоборот. Поскольку день недели несложно вычислить по дате (см. Приложение B), его не нужно включать в формат.

5.5. Простота

Полный набор форматов даты и времени в ISO 8601 [ISO8601] достаточно сложен из-за попыток обеспечить разные и неполные представления. В Приложении A показана попытка преобразовать полный синтаксис ISO 8601 в ABNF. Протоколы Internet имеют иные требования и простота является важным параметром. Кроме того, для протоколов Internet обычно требуется полная спецификация данных для обеспечения совместимости. Поэтому полная грамматика ISO 8601 представляется слишком сложной для большинства протоколов Internet. В следующем параграфе задан профиль ISO 8601 для применения в Internet, являющийся подмножеством расширенного формата ISO 8601. Простота обеспечивается за счёт обязательности большинства полей и пунктуации.

5.6. Формат даты и времени в Internet

Приведённый ниже профиль дат ISO 8601 [ISO8601] следует использовать в новых протоколах Internet. Профиль указан с использованием нотации [ABNF].

Синтаксис создания full-time предназначен для протоколов, которые хотят передавать точные метки времени (например, для записи в журнал или упорядочения событий). Другие варианты (full-date, full-time, partial-time) могут применяться приложениями с соответствующими требованиями².

   date-fullyear   = 4DIGIT
   date-month      = 2DIGIT  ; 01-12
   date-mday       = 2DIGIT  ; 01-28, 01-29, 01-30, 01-31 - месяц-год
   time-hour       = 2DIGIT  ; 00-23
   time-minute     = 2DIGIT  ; 00-59
   time-second     = 2DIGIT  ; 00-58, 00-59, 00-60 с правилами для
                             ; високосных секунд
   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

Примечание. В соответствии с [ABNF] и ISO8601 симаолы T и Z в могут использоваться и в нижнем регистре (t, z).

Этот формат даты и времени может применяться в средах или контексте, где строчные и прописные буквы различаются (например, XML). Спецификации, применяющие этот формат в таких средах, могут дополнительно ограничивать синтаксис, чтобы с дате и времени всегда применялись заглавные буквы T и Z. Приложениям, создающим метки в таком формате, следует использовать заглавные буквы.

Примечание. ISO 8601 разделяет дату и время символом T. Приложения, использующие этот синтаксис могут для удобочитаемости указывать полную дату и полное время, разделённые другим символом (например, пробелом).

5.7. Ограничения

Элемент грамматики date-mday представляет номер дня в текущем месяце. Максимальные значения приведены ниже.

 

Номер месяца	Месяц	Максимальное значение date-mday
01	январь	31
02	февраль обычного года	28
02	февраль високосного года	29
03	март	31
04	апрель	30
05	май	31
06	июнь	30
07	июль	31
08	август	31
09	сентябрь	30
10	октябрь	31
11	ноябрь	30
12	декабрь	31

 

В приложении C приведён код C для определения високосных годов.

Элемент грамматики time-second может иметь значение 60 в конце месяца с високосной секундой, на сегодняшний день это июнь (XXXX-06-30T23:59:60Z) или December (XXXX-12-31T23:59:60Z) (см. Приложение D с таблицей добавления секунды). Возможно также вычитание високосной секунды и максимальное значение time-second составит 58. Во всех других случаях максимальное значение time-second составляет 59. Кроме того, в часовых поясах, отличных от Z, момент учёта високосной секунды сдвигается на величину смещения часового пояса (чтобы секунда учитывалась на всей планете одновременно).

Високосные секунды можно предсказать далеко в будущее. Международная служба вращения Земли (International Earth Rotation Service) публикует бюллетени [IERS], анонсирующие високосные секунды с предупреждением за несколько недель. Приложениям не следует создавать метки времени с учётом високовной секунды до её анонса.

Хотя ISO 8601 разрешает указывать для часа значение 24, этот профиль ISO 8601 разрешает лишь значения от 00 до 23 для снижения путаницы.

5.8. Примеры

Ниже приведены несколько примеров даты и времени в Internet.

      1985-04-12T23:20:50.52Z

Это представляет время 20 минут и 50,52 секунд после 23 часов 12 апреля 1985 г. в UTC.

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

Это представляет время 39 минут и 57 секунд после 16 часов 19 декабря 1996 г со смещением -08:00 от UTC (Pacific Standard Time). Эквивалентом служит 1996-12-20T00:39:57Z in UTC.

      1990-12-31T23:59:60Z

Это представляет високосную секунду, добавленную в конце 1990 г.

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

Это представляет ту же високосную секунду в часовом поясе Pacific Standard Time в 8 часах после UTC.

      1937-01-01T12:00:27.87+00:20

Это представляет тот же момент времени, что и полдень 1 января 1937 г. по времени Нидерландов. Стандартное время в Нидерландах по закону от 1 мая 1909 г. опережало UTC на 19 минут и 32,13 секунд вплоть до 30 июня 1937 г. Это время нельзя точно представить в формате HH:MM и метка использует ближайшее представимое смещение от UTC.

6. Литература

[ZELLER] Zeller, C., “Kalender-Formeln”, Acta Mathematica, Vol. 9, Nov 1886.

[IMAIL] Crocker, D., “Standard for the Format of Arpa Internet Text Messages”, STD 11, RFC 822, August 1982.

[IMAIL-UPDATE] Resnick, P., “Internet Message Format”, RFC 2822, April 2001.

[ABNF] Crocker, D. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF”, RFC 2234, November 1997.

[ISO8601] “Data elements and interchange formats — Information interchange — Representation of dates and times”, ISO 8601:1988(E), International Organization for Standardization, June, 1988.

[ISO8601:2000] “Data elements and interchange formats — Information interchange — Representation of dates and times”, ISO 8601:2000, International Organization for Standardization, December, 2000.

[HOST-REQ] Braden, R., “Requirements for Internet Hosts — Application and Support”, STD 3, RFC 1123, October 1989.

[IERS] International Earth Rotation Service Bulletins, <http://hpiers.obspm.fr/eop-pc/products/bulletins/bulletins.html>³.

[NTP] Mills, D, “Network Time Protocol (Version 3) Specification, Implementation and Analysis”, RFC 1305, March 1992.

[ITU-R-TF] International Telecommunication Union Recommendations for Time Signals and Frequency Standards Emissions. <http://www.itu.ch/publications/itu-r/iturtf.htm>

[RFC2119] Bradner, S, “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, March 1997.

7. Вопросы безопасности

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

Приложение A. ISO 8601 в представлении ABNF

Приведённая здесь информация основана на версии 1988 г. стандарта ISO 8601. В выпуске 2000 г. могут быть некоторые отличия.

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

Отметим, что по причине неоднозначности ISO 8601 пришлось применить некоторые интерпретации. Во-первых, из ISO 8601 не ясно, допускается ли сочетание базового и расширенного формата. Приведённая здесь грамматика разрешает такое смешение⁴. Из ISO 8601 не ясно, допустимо ли значение часа 24 лишь в том случае, когда для минут и секунд установлены значения 0. Это предполагает возможность использовать для часа значение 24 в любом контексте. Применяются ограничения для date-mday из параграфа 5.7. В ISO 8601 сказано, что в некоторых случаях символ T можно пропускать. Описанная здесь грамматика требует использовать T для предотвращения неоднозначности. ISO 8601 требует (параграф 5.3.1.3), чтобы десятичное значение начиналось с 0, если оно меньше единицы⁵.

   date-century    = 2DIGIT  ; 00-99
   date-decade     =  DIGIT  ; 0-9
   date-subdecade  =  DIGIT  ; 0-9
   date-year       = date-decade date-subdecade
   date-fullyear   = date-century date-year
   date-month      = 2DIGIT  ; 01-12
   date-wday       =  DIGIT  ; 1-7  ; 1 - понедельник, 7 - воскресенье
   date-mday       = 2DIGIT  ; 01-28, 01-29, 01-30, 01-31 месяц-год
   date-yday       = 3DIGIT  ; 001-365, 001-366 по годам
   date-week       = 2DIGIT  ; 01-52, 01-53 по году

   datepart-fullyear = [date-century] date-year ["-"]
   datepart-ptyear   = "-" [date-subdecade ["-"]]
   datepart-wkyear   = datepart-ptyear / datepart-fullyear

   dateopt-century   = "-" / date-century
   dateopt-fullyear  = "-" / datepart-fullyear
   dateopt-year      = "-" / (date-year ["-"])
   dateopt-month     = "-" / (date-month ["-"])
   dateopt-week      = "-" / (date-week ["-"])

   datespec-full     = datepart-fullyear date-month ["-"] date-mday
   datespec-year     = date-century / dateopt-century date-year
   datespec-month    = "-" dateopt-year date-month [["-"] date-mday]
   datespec-mday     = "--" dateopt-month date-mday
   datespec-week     = datepart-wkyear "W"
                       (date-week / dateopt-week date-wday)
   datespec-wday     = "---" date-wday
   datespec-yday     = dateopt-fullyear date-yday

   date              = datespec-full / datespec-year / datespec-month /
   datespec-mday / datespec-week / datespec-wday / datespec-yday

Время

   time-hour         = 2DIGIT ; 00-24
   time-minute       = 2DIGIT ; 00-59
   time-second       = 2DIGIT ; 00-58, 00-59, 00-60 с правилами для
                              ; високосных секунд
   time-fraction     = ("," / ".") 1*DIGIT
   time-numoffset    = ("+" / "-") time-hour [[":"] time-minute]
   time-zone         = "Z" / time-numoffset

   timeopt-hour      = "-" / (time-hour [":"])
   timeopt-minute    = "-" / (time-minute [":"])

   timespec-hour     = time-hour [[":"] time-minute [[":"] time-second]]
   timespec-minute   = timeopt-hour time-minute [[":"] time-second]
   timespec-second   = "-" timeopt-minute time-second
   timespec-base     = timespec-hour / timespec-minute / timespec-second

   time              = timespec-base [time-fraction] [time-zone]

   iso-date-time     = date "T" time

Продолжительность

   dur-second        = 1*DIGIT "S"
   dur-minute        = 1*DIGIT "M" [dur-second]
   dur-hour          = 1*DIGIT "H" [dur-minute]
   dur-time          = "T" (dur-hour / dur-minute / dur-second)
   dur-day           = 1*DIGIT "D"
   dur-week          = 1*DIGIT "W"
   dur-month         = 1*DIGIT "M" [dur-day]
   dur-year          = 1*DIGIT "Y" [dur-month]
   dur-date          = (dur-day / dur-month / dur-year) [dur-time]

   duration          = "P" (dur-date / dur-time / dur-week)

Периоды

   period-explicit   = iso-date-time "/" iso-date-time
   period-start      = iso-date-time "/" duration
   period-end        = duration "/" iso-date-time

   period            = period-explicit / period-start / period-end

Приложение B. Дни недели

Ниже приведён пример подпрограммы C, основанной на конгруэнтности Целлера (Zeller’s Congruence) [Zeller], которую можно использовать для определения для недели по дате после 0000-03-01.

   char *day_of_week(int day, int month, int year)
   {
      int cent;
      char *dayofweek[] = {
         "Sunday", "Monday", "Tuesday", "Wednesday",
         "Thursday", "Friday", "Saturday"
      };
      /* настройка месяцев, чтобы февраль был последним */
      month -= 2;
      if (month < 1) {
         month += 12;
         --year;
      }
      /* деление по векам */
      cent = year / 100;
      year %= 100;
      return (dayofweek[((26 * month - 2) / 10 + day + year
                        + year / 4 + cent / 4 + 5 * cent) % 7]);
   }

Приложение C. Високосные годы

Ниже приведён пример на C для определения високосных лет.

   /* Возвращает ненулевое значение для високосных лет. Год должен 
      указываться 4 цифрами.
    */
   int leap_year(int year)
   {
       return (year % 4 == 0 && (year % 100 != 0 || year % 400 == 0));
   }

Приложение D. Високосные секунды

Сведения о високосных секундах можно получить по ссылке <http://tycho.usno.navy.mil/leapsec.html>. В частности, так указано.

За решения по високосным секундам отвечает Международная служба вращения Земли (IERS). В соответствии с рекомендацией CCIR, предпочтение отдаётся последним числам декабря и июня затем – последним числам марта и сентября.

При необходимости високосная секунда добавляется в конце суток UTC и представляется меткой времени вида YYYY-MM-DDT23:59:60Z. Високосная секунда добавляется одновременно во всех часовых поясах, чтобы не нарушались их взаимосвязи. Примеры для високосных секунд приведены в параграфе 5.8.

Ниже приведена выдержка из таблицы Военно-морской обсерватории США (United States Naval Observatory), доступной по ссылке <ftp://maia.usno.navy.mil/ser7/tai-utc.dat>. В таблице указаны даты добавления високосных секунд и разница между стандартом времени TAI (не учитывает високосных секунд) и UTC после добавления високосной секунды.

 

Дата UTC	TAI – UTC после високосной секунды
1972-06-30	11
1972-12-31	12
1973-12-31	13
1974-12-31	14
1975-12-31	15
1976-12-31	16
1977-12-31	17
1978-12-31	18
1979-12-31	19
1981-06-30	20
1982-06-30	21
1983-06-30	22
1985-06-30	23
1987-12-31	24
1989-12-31	25
1990-12-31	26
1992-06-30	27
1993-06-30	28
1994-06-30	29
1995-12-31	30
1997-06-30	31
1998-12-31	32

 

Благодарности

Ned Freed, Neal McBurnett, David Keegel, Markus Kuhn, Paul Eggert и Robert Elz предоставили полезные советы для ранних вариантов документа. Спасибо участникам списка рассылки рабочей группы IETF Calendaring/Scheduling и списка рассылки по часовым поясам.

Tom Harsch, Markus Kuhn, Pete Resnick, Dan Kohn внесли полезные предложения для окончательного документа. Paul Eggert сделал много аккуратных наблюдений относительно тонкостей високосных секунд и смещения часовых поясов. Dr John Stockton, Jutta Degener, Joe Abley, Dan Wing внесли правки и улучшения в ранние варианты документа.

Адреса авторов

Полное заявление авторских прав

Copyright (C) The Internet Society (2002). Все права защищены.

Этот документ и его переводы могут копироваться и предоставляться другим лицам, а производные работы, комментирующие или иначе разъясняющие документ или помогающие в его реализации, могут подготавливаться, копироваться, публиковаться и распространяться целиком или частично без каких-либо ограничений при условии сохранения указанного выше уведомления об авторских правах и этого параграфа в копии или производной работе. Однако сам документ не может быть изменён каким-либо способом, таким как удаление уведомления об авторских правах или ссылок на Internet Society или иные организации Internet, за исключением случаев, когда это необходимо для разработки стандартов Internet (в этом случае нужно следовать процедурам для авторских прав, заданных процессом Internet Standards), а также при переводе документа на другие языки.

Предоставленные выше ограниченные права являются бессрочными и не могут быть отозваны Internet Society или правопреемниками.

Этот документ и содержащаяся в нем информация представлены “как есть” и автор, организация, которую он/она представляет или которая выступает спонсором (если таковой имеется), Internet Society и IETF отказываются от каких-либо гарантий (явных или подразумеваемых), включая (но не ограничиваясь) любые гарантии того, что использование представленной здесь информации не будет нарушать чьих-либо прав, и любые предполагаемые гарантии коммерческого использования или применимости для тех или иных задач.

Подтверждение

Финансирование функций RFC Editor обеспечено Internet Society.

---

Перевод на русский язык

Николай Малых

nmalykh@protokols.ru