ISO 8601 — это международный стандарт, охватывающий всемирный обмен и передачу данных, связанных с датой и временем . Он поддерживается Международной организацией по стандартизации (ISO) и был впервые опубликован в 1988 году с обновлениями в 1991, 2000, 2004 и 2019 годах, а также поправкой в 2022 году. [1] Стандарт предоставляет четко определенный, недвусмысленный метод представления календарных дат и времени в международных сообщениях, особенно для того, чтобы избежать неправильного толкования числовых дат и времени, когда такие данные передаются между странами с разными соглашениями для записи числовых дат и времени.
ISO 8601 применяется к следующим представлениям и форматам: даты в григорианском календаре (включая пролептический григорианский календарь); время , основанное на 24-часовой системе отсчета времени , с необязательным смещением относительно UTC ; временные интервалы ; и их комбинации. [2] Стандарт не присваивает конкретного значения ни одному из представленных элементов дат/времени: значение любого элемента зависит от контекста его использования. Представленные даты и время не могут использовать слова, которые не имеют определенного числового значения в стандарте (таким образом, исключая названия лет в китайском календаре ), или которые не используют компьютерные символы (исключая изображения или звуки). [2]
В представлениях, которые соответствуют стандарту обмена ISO 8601 , даты и время организованы таким образом, что наибольший временной термин (обычно год) размещается слева, а каждый последующий меньший термин размещается справа от предыдущего термина. Представления должны быть записаны в комбинации арабских цифр и определенных компьютерных символов (таких как "-", ":", "T", "W", "Z"), которым присвоены определенные значения в стандарте; то есть такие общие дескрипторы дат (или частей дат), как "Январь", "Четверг" или "Новый год", не допускаются в представлениях обмена в стандарте.
Первое издание стандарта ISO 8601 было опубликовано как ISO 8601:1988 в 1988 году. Он объединил и заменил ряд старых стандартов ISO по различным аспектам обозначения даты и времени: ISO 2014 , ISO 2015 , ISO 2711 , ISO 3307 и ISO 4031. [3] Он был заменен вторым изданием ISO 8601:2000 в 2000 году, третьим изданием ISO 8601:2004, опубликованным 1 декабря 2004 года, и отозван и пересмотрен ISO 8601-1:2019 и ISO 8601-2:2019 25 февраля 2019 года. ISO 8601 был подготовлен [4] и находится под прямой ответственностью Технического комитета ISO TC 154. [5]
ISO 2014, хотя и был заменен, является стандартом, который изначально ввел полностью числовую нотацию дат в порядке от наибольшего к наименьшему значению [YYYY]-[MM]-[DD] . Система нумерации недель ISO была введена в ISO 2015, а идентификация дней по порядковым датам была первоначально определена в ISO 2711.
Выпущенная в феврале 2019 года [6] , четвертая редакция стандарта ISO 8601-1:2019 представляет собой слегка обновленное содержание предыдущего стандарта ISO 8601:2004, [7] [8] тогда как новый стандарт ISO 8601-2:2019 определяет различные расширения, такие как неопределенности или части расширенного формата даты/времени (EDTF). [9] [10] [11] [12] [13] [14]
Поправка была опубликована в октябре 2022 года с небольшими техническими пояснениями и попытками устранить двусмысленности в определениях. Однако наиболее значительным изменением стало повторное введение формата «24:00:00» для обозначения момента в конце календарного дня.
Стандарт использует григорианский календарь , который «служит международным стандартом для гражданского использования». [19]
ISO 8601:2004 фиксирует опорную календарную дату по григорианскому календарю 20 мая 1875 года как дату подписания Конвенции о метре ( Convention du Mètre ) в Париже (явная опорная дата была удалена в ISO 8601-1:2019). Однако даты календаря ISO до конвенции по-прежнему совместимы с григорианским календарем вплоть до официального введения григорианского календаря 15 октября 1582 года.
Более ранние даты в пролептическом григорианском календаре могут использоваться по взаимному согласию партнеров, обменивающихся информацией. Стандарт гласит, что каждая дата должна быть последовательной, поэтому использование юлианского календаря противоречило бы стандарту (потому что на дату перехода даты не будут последовательными).
ISO 8601 предписывает, как минимум, четырехзначный год [YYYY], чтобы избежать проблемы 2000 года . Таким образом, он представляет годы с 0000 по 9999, причем 0000 год равен 1 г. до н. э. , а все остальные — 1 г. н. э. , аналогично астрономической нумерации лет . Однако годы до 1583 г. (первый полный год после введения григорианского календаря ) автоматически не допускаются стандартом. Вместо этого стандарт гласит, что «значения в диапазоне от [0000] до [1582] должны использоваться только по взаимному согласию партнеров по обмену информацией». [20]
Для представления лет до 0000 или после 9999 стандарт также допускает расширение представления года, но только по предварительному соглашению между отправителем и получателем. [21] Расширенное представление года [± Y YYYY] должно иметь согласованное количество дополнительных цифр года сверх четырехзначного минимума, и оно должно быть предварено знаком + или − [22] вместо более распространенной нотации AD/BC (или CE/BCE ); по соглашению 1 BC обозначается +0000 , 2 BC обозначается −0001 и т. д. [23]
Представление календарной даты имеет вид, показанный в соседнем поле. [YYYY] обозначает год из четырех цифр, от 0000 до 9999. [MM] обозначает месяц года из двух цифр, от 01 до 12. [DD] обозначает день этого месяца из двух цифр, от 01 до 31. Например, «5 апреля 1981 года» может быть представлено как «1981-04-05» [15] в расширенном формате или «19810405» в базовом формате .
Стандарт также позволяет записывать календарные даты с уменьшенной точностью. Например, можно написать «1981-04», чтобы обозначить «1981 Апрель». Можно просто написать «1981», чтобы обозначить этот год, «198» — чтобы обозначить десятилетие с 1980 по 1989 включительно, или «19» — чтобы обозначить столетие с 1900 по 1999 включительно. Хотя стандарт допускает как форматы «YYYY-MM-DD» , так и YYYYMMDD для полного представления календарной даты, если день [DD] опущен, то допускается только формат YYYY-MM . Запрещая даты в форме YYYYMM, стандарт избегает путаницы с усеченным представлением [1] [3] YYMMDD (которое все еще часто используется). В версии 2000 года также разрешалось писать сокращение «--04-05» , означающее «5 апреля» [25], но версия 2004 года не позволяет опускать год, если указан месяц.
Примеры:
Представление даты недели имеет форматы, показанные в соседнем поле. [YYYY] обозначает год по системе нумерации недель ISO , который немного отличается от традиционного года григорианского календаря (см. ниже). [Www] — это номер недели с префиксом в виде буквы W , от W01 до W53. [D] — это номер дня недели , от 1 до 7, начиная с понедельника и заканчивая воскресеньем.
Существует несколько взаимно эквивалентных и совместимых описаний недели 01:
Как следствие, если 1 января приходится на понедельник, вторник, среду или четверг, то он находится на 01-й неделе. Если 1 января приходится на пятницу, субботу или воскресенье, то он находится на 52-й или 53-й неделе предыдущего года (недели 00 нет). 28 декабря всегда находится на последней неделе своего года.
Номер недели можно определить, подсчитав четверги: 12-я неделя содержит 12-й четверг года.
Год по нумерации недель ISO начинается в первый день (понедельник) недели 01 и заканчивается в воскресенье перед новым годом ISO (следовательно, без наложения или разрыва). Он состоит из 52 или 53 полных недель. Первая неделя ISO года может иметь до трех дней, которые фактически попадают в год григорианского календаря, который заканчивается; если три, то это понедельник, вторник и среда. Аналогично, последняя неделя ISO года может иметь до трех дней, которые фактически попадают в год григорианского календаря, который начинается; если три, то это пятница, суббота и воскресенье. Четверг каждой недели ISO всегда находится в году григорианского календаря, обозначенном годом нумерации недель ISO.
Примеры:
Порядковая дата — это порядковый формат для кратных дней, прошедших с начала года. Он представлен как «YYYY-DDD» (или YYYYDDD), где [YYYY] обозначает год, а [DDD] — «день года», от 001 до 365 (366 в високосные годы ). Например, «1981-04-05» — это то же самое, что и «1981-095» .
Эта простая форма предпочтительна для случаев, когда произвольный характер определений недель и месяцев является скорее помехой, чем помощью, например, при сравнении дат из разных календарей. Этот формат используется с простыми аппаратными системами, которым нужна система дат, но где включение полного программного обеспечения для расчета календаря может быть существенным неудобством. Эту систему иногда называют «юлианской датой», но это может вызвать путаницу с астрономическим юлианским днем , последовательным подсчетом количества дней с дня 0, начинающегося 1 января 4713 г. до н. э. Гринвичский полдень, юлианский пролептический календарь (или полдень в дату ISO −4713-11-24 , которая использует григорианский пролептический календарь с годом 0000).
ISO 8601 использует 24-часовую систему времени. Начиная с ISO 8601-1:2019, базовый формат — T[чч][мм][сс], а расширенный формат — T[чч]:[мм]:[сс]. В более ранних версиях в обоих форматах отсутствовала буква T (представляющая время).
Таким образом, время может отображаться как «T134730» в базовом формате или как «T13:47:30» в расширенном формате . ISO 8601-1:2019 допускает пропуск T в расширенном формате, например, «13:47:30», но допускает пропуск T в базовом формате только в том случае, если нет риска путаницы с выражениями даты.
Секунды или минуты и секунды могут быть опущены в базовом или расширенном форматах времени для большей краткости, но снижения точности; в результате получаются следующие форматы времени с пониженной точностью: [26]
В ISO 8601-1:2019/Amd 1:2022 «00:00:00» может использоваться для обозначения полуночи , соответствующей моменту начала календарного дня; а «24:00:00» — для обозначения полуночи, соответствующей моменту конца календарного дня. [1] В первоначально опубликованном стандарте ISO 8601-1:2019 «24:00:00» удалено как обозначение конца дня, хотя это было разрешено в более ранних версиях стандарта.
Десятичная дробь может быть добавлена к элементу времени самого низкого порядка, присутствующему в любом из этих представлений. Десятичный знак , либо запятая , либо точка на базовой линии , используется в качестве разделителя между элементом времени и его дробью. (Следуя ISO 80000-1 согласно ISO 8601:1-2019, [27] он не предусматривает предпочтения, за исключением международных стандартов, но с предпочтением запятой согласно ISO 8601:2004. [28] ) Например, чтобы обозначить «14 часов, 30 с половиной минут», не включайте цифру секунд; представьте это как «14:30,5», «T1430,5», «14:30.5» или «T1430.5».
Нет ограничений на количество знаков после запятой для десятичной дроби. Однако количество знаков после запятой должно быть согласовано общающимися сторонами. Например, в Microsoft SQL Server точность десятичной дроби составляет 3 для DATETIME, т.е. "yyyy-mm-ddThh:mm:ss[.mmm]". [29]
Часовые пояса в ISO 8601 представлены как местное время (местоположение не указано), как UTC или как смещение от UTC.
Если информация о соотношении с UTC не указана вместе с представлением времени, предполагается, что время указано по местному времени. Хотя при общении в одном часовом поясе можно с уверенностью предположить местное время, при общении в разных часовых поясах оно неоднозначно. Даже в пределах одного географического часового пояса некоторые местные времена будут неоднозначными, если в регионе действует летнее время . Обычно предпочтительнее указывать часовой пояс (обозначение пояса), используя обозначение стандарта.
Если время указано в формате UTC , добавьте Z сразу после времени без пробела. Z — это обозначение пояса для нулевого смещения UTC. Таким образом, «09:30 UTC» представляется как «09:30Z» или «T0930Z». «14:45:15 UTC» будет представлено как «14:45:15Z» или «T144515Z».
Суффикс Z в обозначении времени ISO 8601 иногда называют «зулусским временем» или «зулусским меридианом», поскольку эта же буква используется для обозначения часового пояса Зулу . [30] Однако стандарт ACP 121, определяющий список военных часовых поясов, не упоминает UTC и выводит «зулусское время» из среднего времени по Гринвичу [31] , которое ранее использовалось в качестве международного гражданского стандарта времени. GMT больше не имеет точного определения в научном сообществе и может относиться как к UTC, так и к UT1 в зависимости от контекста. [32]
Смещение UTC добавляется непосредственно ко времени вместо суффикса "Z" выше; другие буквы морского часового пояса не используются. Смещение применяется к UTC для получения гражданского времени в указанном часовом поясе в формате '±[чч]:[мм]', '±[чч][мм]' или '±[чч]'.
Отрицательное смещение UTC описывает часовой пояс к западу от нулевого меридиана , где гражданское время отстает от UTC. Таким образом, обозначение пояса для Нью-Йорка (по стандартному времени ) будет "−05:00", "−0500" или "−05". И наоборот, положительное смещение UTC описывает часовой пояс к востоку от нулевого меридиана, где гражданское время опережает UTC . Таким образом, обозначение пояса для Каира будет "+02:00", "+0200" или "+02".
Часовой пояс, в котором гражданское время совпадает с UTC, всегда обозначается как положительный, хотя смещение равно нулю (см. соответствующие спецификации ниже). Таким образом, обозначение пояса для Лондона (по стандартному времени ) будет " +00:00 ", " +0000 " или " +00 ".
Другие смещения относительно UTC см. в разделе Список смещений относительно UTC .
Не разрешается указывать нулевое значение смещения времени с отрицательным знаком, как "−00:00", "−0000" или "−00". Раздел, определяющий использование знаков, гласит, что знак плюс должен использоваться для положительного или нулевого значения, а знак минус для отрицательного значения. Знак плюс-минус ( ± ) также может использоваться, если он доступен. [33]
Вопреки этому правилу, RFC 3339, который в остальном является профилем ISO 8601, разрешает использование «−00» с тем же обозначением, что и «+00», но с другим подтекстом: неизвестное смещение UTC . [34] [35]
Для представления отрицательного смещения ISO 8601 предписывает использовать знак минус ( − ) . Если набор символов обмена ограничен и не имеет символа знака минус, то следует использовать дефис-минус , ( - ). [36] В ASCII нет знака минус, поэтому будет использоваться его символ дефис-минус (код 45 10 ). Если набор символов имеет знак минус, например U+2212 − ЗНАК МИНУС в Unicode , то следует использовать этот символ. Вызов сущности символов HTML для − — −
.
ISO 8601-2:2019 допускает общие длительности для смещений времени. Например, можно добавить больше точности к смещению времени с помощью формата '<время>±[чч]:[мм]:[сс].[сс]' или '<время>±[н]Ч[н]М[н]С', как показано ниже.
Отдельный момент времени может быть представлен путем объединения полного выражения даты, буквы «T» в качестве разделителя и допустимого выражения времени. Например, «2007-04-05T14:30» . В ISO 8601:2004 разрешалось опускать символ «T» по взаимному согласию, как в «200704051430» , [37], но это положение было удалено в ISO 8601-1:2019. Разделение частей даты и времени другими символами, такими как пробел, не допускается в ISO 8601, но допускается в его профиле RFC 3339. [38]
Если требуется указатель часового пояса, он следует за объединенной датой и временем. Например, "2007-04-05T14:30Z" или "2007-04-05T12:30−02:00" .
Можно использовать как базовый, так и расширенный формат, но дата и время должны использовать один и тот же формат. Выражение даты может быть календарным, недельным или порядковым и должно использовать полное представление. Время может быть представлено с использованием указанного формата с пониженной точностью.
Длительности определяют количество промежуточного времени в интервале времени и представлены в формате P[n]Y[n]M[n]DT[n]H[n]M[n]S или P[n]W, как показано сбоку. В этих представлениях [n] заменяется значением для каждого из элементов даты и времени, следующих за [n]. Начальные нули не требуются, но максимальное количество цифр для каждого элемента должно быть согласовано сторонами, взаимодействующими друг с другом. Заглавные буквы P , Y , M , W , D , T , H , M и S являются обозначениями для каждого из элементов даты и времени и не заменяются.
Например, «P3Y6M4DT12H30M5S» представляет собой продолжительность «три года, шесть месяцев, четыре дня, двенадцать часов, тридцать минут и пять секунд».
Элементы даты и времени, включая их обозначение, могут быть опущены, если их значение равно нулю, а элементы более низкого порядка также могут быть опущены для снижения точности. Например, "P23DT23H" и "P4Y" являются приемлемыми представлениями длительности. Однако должен присутствовать по крайней мере один элемент, поэтому "P" не является допустимым представлением для длительности 0 секунд. "PT0S" или "P0D", однако, оба являются допустимыми и представляют одну и ту же длительность.
Чтобы устранить неоднозначность, «P1M» — это длительность в один месяц, а «PT1M» — это длительность в одну минуту (обратите внимание на указатель времени T, который предшествует значению времени). Наименьшее используемое значение может также иметь десятичную дробь, [39] как в «P0.5Y», чтобы указать полгода. Эта десятичная дробь может быть указана либо с запятой , либо с точкой , как в «P0,5Y» или «P0.5Y». Стандарт не запрещает значениям даты и времени в представлении длительности превышать свои «точки переноса», за исключением случаев, указанных ниже. Таким образом, «PT36H» может использоваться так же, как и «P1DT12H» для представления той же длительности. Но имейте в виду, что «PT36H» — это не то же самое, что «P1DT12H» при переключении с или на летнее время .
В качестве альтернативы, формат для продолжительности, основанный на комбинированных представлениях даты и времени, может использоваться по соглашению между общающимися сторонами либо в базовом формате PYYYYMMDDThhmmss, либо в расширенном формате P[YYYY]-[MM]-[DD]T[hh]:[mm]:[ss] . Например, первая продолжительность, показанная выше, будет "P0003-06-04T12:30:05" . Однако отдельные значения даты и времени не могут превышать свои модули (например, значение 13 для месяца или 25 для часа не будет допустимым). [40]
Стандарт описывает длительность как часть временных интервалов, которые обсуждаются в следующем разделе. Формат длительности сам по себе неоднозначен относительно общего количества дней в календарном году и календарном месяце. Количество секунд в календарном дне также неоднозначно из-за високосных секунд . Например, «P1M» сам по себе может быть 28, 29, 30 или 31 день. При использовании во временном интервале неоднозначности нет. Используя пример длительности «P2M» двух календарных месяцев:
Формат продолжительности (или его подмножество) широко используется независимо от временных интервалов, как в случае с классом Duration в Java 8, который поддерживает подмножество формата продолжительности. [41] [42]
Временной интервал — это промежуток времени между двумя точками времени. Количество промежуточного времени выражается длительностью (как описано в предыдущем разделе). Две точки времени (начало и конец) выражаются либо объединенным представлением даты и времени, либо просто представлением даты.
Существует четыре способа выражения временного интервала:
Из них первые три требуют двух значений, разделенных обозначением интервала , которым обычно является косая черта (чаще называемая прямой косой чертой «/»). В разделе 3.2.6 стандарта ISO 8601-1:2019 отмечается, что «косая черта может быть заменена двойным дефисом [«--»] по взаимному соглашению общающихся партнеров», а в предыдущих версиях использовались обозначения типа «2000--2002». [43] Использование двойного дефиса вместо косой черты позволяет включать ее в имена компьютерных файлов ; [44] в распространенных операционных системах косая черта является зарезервированным символом и не допускается в имени файла.
Для выражений <start>/<end>, если какие-либо элементы отсутствуют в конечном значении, предполагается, что они такие же, как и для начального значения, включая часовой пояс. Эта функция стандарта позволяет кратко представлять временные интервалы. Например, дата двухчасовой встречи, включая время начала и окончания, может быть показана как "2007-12-14T13:30/15:30", где "/15:30" подразумевает "/2007-12-14T15:30" (та же дата, что и начало), или даты начала и окончания ежемесячного расчетного периода как "2008-02-15/03-14", где "/03-14" подразумевает "/2008-03-14" (тот же год, что и начало).
Если для представления временного интервала требуется большая точность, то в представление можно добавить больше элементов времени. Интервал, обозначенный как "2007-11-13/15", может начинаться в любое время 2007-11-13 и заканчиваться в любое время 2007-11-15 , тогда как "2007-11-13T09:00/15T17:00" включает начальное и конечное время. Чтобы явно включить все начальные и конечные даты, интервал будет представлен как "2007-11-13T00:00/16T00:00" .
Повторяющиеся интервалы указаны в пункте "4.5 Повторяющийся интервал времени". Они образуются путем добавления "R[n]/" к началу выражения интервала, где R используется как сама буква, а [n] заменяется числом повторений. Пропуск значения для [n] или указание значения -1 означает неограниченное число повторений. Значение 0 для [n] означает, что интервал не повторяется.
Если интервал указывает начало (формы 1 и 2 выше), то это начало повторяющегося интервала. Если интервал указывает конец, но не начало (форма 3 выше), то это конец повторяющегося интервала. Например, чтобы повторить интервал "P1Y2M10DT2H30M" пять раз, начиная с "2008-03-01T13:00:00Z" , используйте "R5/2008-03-01T13:00:00Z/P1Y2M10DT2H30M" .
ISO 8601:2000 допускал усечение (по соглашению), когда начальные компоненты даты или времени опускались. В частности, это позволяло использовать двузначные годы, а также неоднозначные форматы YY-MM-DD и YYMMDD. Это положение было удалено в ISO 8601:2004.
В первом и седьмом примерах, приведенных выше, пропущено начальное значение -
для века. В других форматах пропущено одно начальное значение -
для века, года, месяца, недели, часа и минуты, что необходимо для устранения неоднозначности формата.
ISO 8601-2:2019 определяет набор стандартизированных расширений форматов даты и времени ISO 8601.
В Интернете , World Wide Web Consortium (W3C) использует стандарт IETF , основанный на ISO 8601, определяя профиль стандарта, который ограничивает поддерживаемые форматы даты и времени, чтобы уменьшить вероятность ошибки и сложность программного обеспечения. Очень простая спецификация основана на проекте RFC 3339, упомянутом ниже. [45]
ISO 8601 упоминается в нескольких спецификациях, но не всегда используется полный спектр опций ISO 8601. Например, различные стандарты электронных программ передач для телевидения, цифрового радио и т. д. используют несколько форм для описания моментов времени и продолжительности. Спецификация аудиометаданных ID3 также использует подмножество ISO 8601. [46] Стандарт кодирования X.690 GeneralizedTime использует другое подмножество ISO 8601.
С 2006 года дата недели ISO появляется в своей базовой форме на упаковке основных торговых марок в Соединенных Штатах. [ требуется ссылка ] Ее внешний вид зависел от конкретного завода по упаковке, консервированию или розливу больше, чем от конкретного бренда. Формат особенно полезен для обеспечения качества, так как позволяет легко отслеживать ошибки производства.
IETF RFC 3339 [47] определяет профиль ISO 8601 для использования в интернет-протоколах и стандартах . Он явно исключает длительности и даты до общей эры . Более сложные форматы, такие как номера недель и порядковые номера дней, не допускаются. [48]
RFC 3339 отличается от ISO 8601, позволяя указывать нулевое смещение часового пояса как «-00:00», что запрещено ISO 8601. RFC 3339 подразумевает, что «-00:00» несет в себе коннотацию того, что он не указывает предпочтительный часовой пояс, тогда как соответствующее «+00:00» или любое ненулевое смещение подразумевает, что используемое смещение является предпочтительным. Это соглашение относительно «-00:00» получено из более ранних RFC, таких как RFC 2822, который использует его для временных меток в заголовках электронной почты . [49] RFC 2822 не утверждал, что какая-либо часть его формата временной метки соответствует ISO 8601, и поэтому мог свободно использовать это соглашение без конфликта.
Основываясь на RFC 3339, IETF представила расширенный формат даты/времени в Интернете (IXDTF) в RFC 9557. [50] Этот формат расширяет представление временной метки, включая дополнительную информацию, такую как связанное имя часового пояса. Включение имен часовых поясов особенно полезно для приложений, которым необходимо учитывать такие события, как переходы на летнее время. Кроме того, IXDTF поддерживает совместимость с уже существующим синтаксисом для присоединения имен часовых поясов к временным меткам, предоставляя стандартизированный и гибкий подход к представлению временных меток в Интернете. Пример:
1996-12-19T16:39:57-08:00[America/Los_Angeles]
Приложение A: ... Из этой концепции логически выведены представления всех других значений даты и времени; таким образом, ISO 2014, ISO 3307 и ISO 4031 были заменены. ... Идентификация конкретной даты с помощью порядковых дат (ISO 2711) и с помощью системы нумерации недель (ISO 2015) были альтернативными методами, которые также могла бы охватывать основная концепция этого международного стандарта; таким образом, ISO 2015 и ISO 2711 в настоящее время заменены.
Григорианский календарь сегодня служит международным стандартом для гражданского использования.
3.5 Расширение ... По взаимному соглашению партнеров по обмену информацией разрешается расширять компонент, идентифицирующий календарный год, который в противном случае ограничен четырьмя цифрами. Это позволяет ссылаться на даты и время в календарных годах за пределами диапазона, поддерживаемого полными представлениями, т. е. до начала года [0000] или после окончания года [9999].
Усеченное представление, как указано в [ISO.8601.2000], разделы 5.2.1.3 d), e) и f), разрешено., хотя удален в ISO 8601:2004
Усеченное представление, как указано в [ISO.8601.2000], разделы 5.2.1.3 d), e) и f), разрешено.
4.2.2.4 ... десятичная дробь должна быть отделена от целой части десятичным знаком, указанным в ISO 31-0, т. е. запятой [,] или точкой [.]. Из них запятая является предпочтительным знаком.
Неизвестное локальное соглашение о смещении: если время в формате UTC известно, но смещение относительно местного времени неизвестно, это может быть представлено смещением «-00:00». Это семантически отличается от смещения «Z» или «+00:00», которые подразумевают, что UTC является предпочтительной точкой отсчета для указанного времени. RFC2822 [IMAIL-UPDATE] описывает аналогичное соглашение для электронной почты
В среде, где используется репертуар символов на основе ISO/IEC 646, "дефис" и "минус" оба отображаются на "дефис-минус". Представления с "плюс-минус" должны использоваться только в такой среде, если репертуар обмена включает "плюс-минус"
4.3.2 ПРИМЕЧАНИЕ: По взаимному соглашению партнеров по обмену информацией символ [T] может быть опущен в приложениях, где нет риска перепутать представление даты и времени дня с другими, определенными в настоящем международном стандарте.
5.6. ПРИМЕЧАНИЕ. ISO 8601 определяет дату и время, разделенные символом "T". Приложения, использующие этот синтаксис, могут выбрать, ради удобства чтения, указание полной даты и полного времени, разделенных (например) пробелом.
б) Если это необходимо для конкретного приложения, компоненты низшего порядка могут иметь десятичную дробь.
Обзор внедрения