ISO 8601 es una norma internacional que cubre el intercambio y la comunicación mundial de datos relacionados con la fecha y la hora . Lo mantiene la Organización Internacional de Normalización (ISO) y se publicó por primera vez en 1988, con actualizaciones en 1991, 2000, 2004 y 2019, y una enmienda en 2022. [1] El estándar proporciona un método inequívoco y bien definido. de representar fechas y horas del calendario en las comunicaciones mundiales, especialmente para evitar interpretaciones erróneas de fechas y horas numéricas cuando dichos datos se transfieren entre países con diferentes convenciones para escribir fechas y horas numéricas.
La norma ISO 8601 se aplica a estas representaciones y formatos: fechas , en el calendario gregoriano (incluido el calendario gregoriano proléptico ); horarios , basados en el sistema de cronometraje de 24 horas , con compensación UTC opcional ; intervalos de tiempo ; y combinaciones de los mismos. [2] La norma no asigna un significado específico a ningún elemento de las fechas/horas representadas: el significado de cualquier elemento depende del contexto de su uso. Las fechas y horas representadas no pueden utilizar palabras que no tengan un significado numérico específico dentro del estándar (excluyendo así los nombres de años en el calendario chino ), o que no utilicen caracteres de computadora (excluye imágenes o sonidos). [2]
En las representaciones que cumplen con el estándar de intercambio ISO 8601 , las fechas y horas se organizan de manera que el término temporal mayor (normalmente un año) se coloca a la izquierda y cada término sucesivamente menor se coloca a la derecha del término anterior. Las representaciones deben escribirse en una combinación de números arábigos y caracteres informáticos específicos (como "‐", ":", "T", "W", "Z") a los que se les asignan significados específicos dentro del estándar; es decir, descriptores comunes de fechas (o partes de fechas) como "enero", "jueves" o "año nuevo" no están permitidos en representaciones de intercambio dentro de la norma.
La primera edición de la norma ISO 8601 se publicó como ISO 8601:1988 en 1988. Unificó y reemplazó una serie de normas ISO más antiguas en diversos aspectos de la notación de fecha y hora: ISO 2014 , ISO 2015 , ISO 2711 , ISO 3307 y ISO 4031 . [3] Ha sido reemplazada por una segunda edición ISO 8601:2000 en 2000, por una tercera edición ISO 8601:2004 publicada el 1 de diciembre de 2004, y retirada y revisada por ISO 8601-1:2019 e ISO 8601-2:2019. el 25 de febrero de 2019. ISO 8601 fue preparada por, [4] y está bajo la responsabilidad directa del Comité Técnico de ISO TC 154. [5]
ISO 2014, aunque reemplazada, es el estándar que introdujo originalmente la notación de fecha totalmente numérica en orden de mayor a menos significativo [AAAA]-[MM]-[DD] . El sistema de numeración de semanas ISO se introdujo en ISO 2015 y la identificación de días mediante fechas ordinales se definió originalmente en ISO 2711.
Publicada en febrero de 2019, [6] la cuarta revisión de la norma ISO 8601-1:2019 representa contenidos ligeramente actualizados de la norma ISO 8601:2004 anterior, [7] [8] mientras que la nueva ISO 8601-2:2019 define varios extensiones como incertidumbres o partes del formato extendido de fecha/hora (EDTF). [9] [10] [11] [12] [13] [14]
En octubre de 2022 se publicó una enmienda que incluye aclaraciones técnicas menores e intentos de eliminar ambigüedades en las definiciones. El cambio más significativo, sin embargo, fue la reintroducción del formato "24:00:00" para referirse al instante al final de un día calendario.
La norma utiliza el calendario gregoriano , que "sirve como estándar internacional para uso civil". [19]
ISO 8601:2004 fija una fecha de calendario de referencia al calendario gregoriano del 20 de mayo de 1875 como la fecha en que se firmó la Convención del Metro ( Convención del Metro ) en París (la fecha de referencia explícita se eliminó en ISO 8601-1:2019). Sin embargo, las fechas del calendario ISO anteriores a la convención siguen siendo compatibles con el calendario gregoriano desde la introducción oficial del calendario gregoriano el 15 de octubre de 1582.
Fechas anteriores, en el calendario gregoriano proléptico , podrán ser utilizadas por mutuo acuerdo de los socios que intercambien información. El estándar establece que cada fecha debe ser consecutiva, por lo que el uso del calendario juliano sería contrario al estándar (porque en la fecha de cambio, las fechas no serían consecutivas).
ISO 8601 prescribe, como mínimo, un año de cuatro dígitos [AAAA] para evitar el problema del año 2000 . Por lo tanto, representa los años del 0000 al 9999, siendo el año 0000 igual al 1 a. C. y todos los demás d. C. , similar a la numeración de años astronómicos . Sin embargo, la norma no permite automáticamente los años anteriores a 1583 (el primer año completo después de la introducción del calendario gregoriano ). En cambio, la norma establece que "los valores en el rango [0000] a [1582] sólo se utilizarán por acuerdo mutuo de los socios en el intercambio de información". [20]
Para representar años anteriores a 0000 o posteriores a 9999 , la norma también permite ampliar la representación de los años, pero sólo mediante acuerdo previo entre el remitente y el receptor. [21] Una representación de año ampliada [± Y AAAA] debe tener un número acordado de dígitos de año adicionales más allá del mínimo de cuatro dígitos, y debe tener como prefijo un signo + o − [22] en lugar del más común AD. Notación /BC (o CE/BCE ); por convención, 1 BC se etiqueta como +0000 , 2 BC se etiqueta como −0001, y así sucesivamente. [23]
Las representaciones de fechas del calendario tienen la forma que se muestra en el cuadro adyacente. [AAAA] indica un año de cuatro dígitos, del 0000 al 9999. [MM] indica un mes del año de dos dígitos, del 01 al 12. [DD] indica un día de ese mes de dos dígitos, del 01 al 31. Por ejemplo , "5 de abril de 1981" puede representarse como "1981-04-05" [15] en el formato extendido o "19810405" en el formato básico .
El estándar también permite escribir fechas del calendario con precisión reducida. Por ejemplo, se puede escribir "1981-04" en el sentido de "abril de 1981". Se puede escribir simplemente "1981" para referirse a ese año, "198" para referirse a la década de 1980 a 1989 inclusive, o "19" para referirse al siglo de 1900 a 1999 inclusive. Aunque el estándar permite los formatos "AAAA-MM-DD" y AAAAMMDD para representaciones completas de la fecha del calendario, si se omite el día [DD], solo se permite el formato AAAA-MM . Al no permitir fechas con el formato AAAAMM, el estándar evita la confusión con la representación truncada [1] [3] AAAAMMDD (aún utilizada con frecuencia). La versión de 2000 también permitía escribir el truncamiento "--04-05" para significar "5 de abril" [25] pero la versión de 2004 no permite omitir el año cuando hay un mes presente.
Ejemplos:
Las representaciones de fechas de la semana están en los formatos que se muestran en el cuadro adyacente. [AAAA] indica el año de numeración de semanas ISO que es ligeramente diferente del año calendario gregoriano tradicional (ver más abajo). [Www] es el número de semana precedido por la letra W , desde W01 hasta W53. [D] es el número del día de la semana , del 1 al 7, comenzando con el lunes y terminando con el domingo.
Existen varias descripciones mutuamente equivalentes y compatibles de la semana 01:
En consecuencia, si el 1 de enero es lunes, martes, miércoles o jueves, está en la semana 01. Si el 1 de enero es viernes, sábado o domingo, está en la semana 52 o 53 del año anterior (hay sin semana 00). El 28 de diciembre siempre cae en la última semana de su año.
El número de semana se puede describir contando los jueves: la semana 12 contiene el duodécimo jueves del año.
El año de numeración de semanas ISO comienza el primer día (lunes) de la semana 01 y termina el domingo anterior al nuevo año ISO (por lo tanto, sin superposición ni espacio). Consta de 52 o 53 semanas completas. La primera semana ISO de un año puede tener hasta tres días que realmente estén en el año calendario gregoriano que está finalizando; si son tres, son lunes, martes y miércoles. De manera similar, la última semana ISO de un año puede tener hasta tres días que realmente estén en el año calendario gregoriano que está iniciando; si son tres, son viernes, sábado y domingo. El jueves de cada semana ISO siempre está en el año calendario gregoriano indicado por el año de numeración de la semana ISO.
Ejemplos:
Una fecha ordinal es un formato ordinal para los múltiplos de un día transcurrido desde el inicio del año. Se representa como "AAAA-DDD" (o AAAADDD), donde [AAAA] indica un año y [DDD] es el "día del año", desde 001 hasta 365 (366 en años bisiestos ). Por ejemplo, "1981-04-05" es lo mismo que "1981-095" .
Esta forma sencilla es preferible en ocasiones en las que la naturaleza arbitraria de las definiciones de semana y mes es más un impedimento que una ayuda, por ejemplo, al comparar fechas de diferentes calendarios. Este formato se utiliza con sistemas de hardware simples que necesitan un sistema de fecha, pero donde incluir un software de cálculo de calendario completo puede ser una molestia importante. Este sistema a veces se denomina "fecha juliana", pero esto puede causar confusión con el día juliano astronómico , un recuento secuencial del número de días desde el día 0 que comienza el 1 de enero de 4713 a. C. Mediodía de Greenwich, calendario proléptico juliano (o mediodía en ISO fecha −4713-11-24 que utiliza el calendario proléptico gregoriano con año 0000).
ISO 8601 utiliza el sistema de reloj de 24 horas . A partir de ISO 8601-1:2019, el formato básico es T[hh][mm][ss] y el formato extendido es T[hh]:[mm]:[ss]. Las versiones anteriores omitían la T (que representa la hora) en ambos formatos.
Por lo tanto, una hora puede aparecer como "T134730" en el formato básico o "T13:47:30" en el formato extendido . ISO 8601-1:2019 permite omitir la T en el formato extendido, como en "13:47:30", pero solo permite omitir la T en el formato básico cuando no hay riesgo de confusión con expresiones de fecha.
Se pueden omitir los segundos, o los minutos y segundos, en los formatos de hora básico o extendido para mayor brevedad pero menor precisión; Los formatos de tiempo de precisión reducida resultantes son: [26]
A partir de ISO 8601-1:2019/Amd 1:2022, se puede utilizar "00:00:00" para referirse a la medianoche correspondiente al instante del inicio de un día calendario; y "24:00:00" para referirse a la medianoche correspondiente al instante del final de un día natural. [1] ISO 8601-1:2019, tal como se publicó originalmente, eliminó "24:00:00" como representación del final del día, aunque se había permitido en versiones anteriores de la norma.
Se puede agregar una fracción decimal al elemento de tiempo de orden más bajo presente en cualquiera de estas representaciones. Una marca decimal , ya sea una coma o un punto en la línea base , se utiliza como separador entre el elemento de tiempo y su fracción. (Siguiendo la norma ISO 80000-1 según ISO 8601:1-2019, [27] no estipula preferencia excepto dentro de Normas Internacionales, pero sí con preferencia por coma según ISO 8601:2004. [28] ) Por ejemplo, para indicar "14 horas, 30 minutos y medio", no incluya la cifra de segundos; represéntelo como "14:30,5", "T1430,5", "14:30.5" o "T1430.5".
No hay límite en el número de decimales para la fracción decimal. Sin embargo, el número de decimales debe ser acordado por las partes comunicantes. Por ejemplo, en Microsoft SQL Server, la precisión de una fracción decimal es 3 para DATETIME, es decir, "yyyy-mm-ddThh:mm:ss[.mmm]". [29]
Las zonas horarias en ISO 8601 se representan como hora local (sin especificar la ubicación), como UTC o como una diferencia con respecto a UTC.
Si no se proporciona información de relación UTC con una representación de la hora, se supone que la hora está en la hora local. Si bien puede ser seguro asumir la hora local cuando se comunica en la misma zona horaria, es ambiguo cuando se utiliza para comunicarse entre diferentes zonas horarias. Incluso dentro de una única zona horaria geográfica, algunas horas locales serán ambiguas si la región observa el horario de verano . Generalmente es preferible indicar una zona horaria (designador de zona) utilizando la notación estándar.
Si la hora está en UTC , agregue una Z directamente después de la hora sin espacio. Z es el designador de zona para el desplazamiento cero UTC. Por lo tanto, "09:30 UTC" se representa como "09:30Z" o "T0930Z". "14:45:15 UTC" sería "14:45:15Z" o "T144515Z".
El sufijo Z en la representación de la hora ISO 8601 a veces se denomina "hora zulú" o "meridiano zulú" porque se utiliza la misma letra para designar la zona horaria zulú . [30] Sin embargo, el estándar ACP 121 que define la lista de zonas horarias militares no menciona UTC y deriva la "hora zulú" de la hora media de Greenwich [31] que se utilizaba anteriormente como estándar de hora civil internacional. GMT ya no está definido con precisión por la comunidad científica y puede referirse a UTC o UT1 según el contexto. [32]
El desplazamiento UTC se agrega directamente a la hora en lugar del sufijo "Z" anterior; no se utilizan otras letras de zona horaria náutica . El desplazamiento se aplica a UTC para obtener la hora civil en la zona horaria designada en el formato '±[hh]:[mm]', '±[hh][mm]' o '±[hh]'.
Un desplazamiento UTC negativo describe una zona horaria al oeste del meridiano principal donde la hora civil está por detrás de UTC. Entonces, la designación de zona para Nueva York (en hora estándar ) sería "−05:00", "-0500" o "-05". Por el contrario, un desplazamiento UTC positivo describe una zona horaria al este del meridiano principal donde la hora civil está adelantada a UTC . Entonces, la designación de zona para El Cairo será "+02:00", "+0200" o "+02".
Una zona horaria donde la hora civil coincide con UTC siempre se designa como positiva, aunque el desplazamiento es cero (consulte las especificaciones relacionadas a continuación). Entonces, la designación de zona para Londres (en horario estándar ) sería " +00:00 ", " +0000 " o " +00 ".
Consulte la Lista de compensaciones UTC para conocer otras compensaciones UTC .
No está permitido indicar un desplazamiento de tiempo de valor cero con un signo negativo, como "−00:00", "−0000" o "−00". La sección que dicta el uso de signos establece que se debe usar un signo más para un valor positivo o cero, y un signo menos para un valor negativo. También se puede utilizar un signo más-menos ( ± ) si está disponible. [33]
Contrariamente a esta regla, RFC 3339, que por lo demás es un perfil de ISO 8601, permite el uso de "−00" con la misma denotación que "+00" pero con una connotación diferente: un desplazamiento UTC desconocido . [34] [35]
Para representar un desplazamiento negativo, ISO 8601 especifica el uso de un signo menos ( - ) . Si el conjunto de caracteres de intercambio es limitado y no tiene un carácter de signo menos, entonces se debe utilizar el guión menos ( - ). [36] ASCII no tiene un signo menos, por lo que se utilizaría su carácter de guión menos (código 45 10 ). Si el conjunto de caracteres tiene un signo menos, como U+2212 − SIGNO MENOS en Unicode , entonces se debe utilizar ese carácter. La invocación de entidad de caracteres HTML para − es −.
ISO 8601-2:2019 permite duraciones generales para compensaciones horarias. Por ejemplo, se puede agregar más precisión al desplazamiento de tiempo con el formato '<hora>±[hh]:[mm]:[ss].[sss]' o '<hora>±[n]H[n]M [n]S' como se muestra a continuación.
Un único punto en el tiempo se puede representar concatenando una expresión de fecha completa, la letra "T" como delimitador y una expresión de tiempo válida. Por ejemplo, "2007-04-05T14:30" . En ISO 8601:2004 se permitía omitir el carácter "T" de mutuo acuerdo como en "200704051430" , [37] pero esta disposición se eliminó en ISO 8601-1:2019. Separar partes de fecha y hora con otros caracteres como espacios no está permitido en ISO 8601, pero sí en su perfil RFC 3339. [38]
Si se requiere un designador de zona horaria, sigue a la fecha y hora combinadas. Por ejemplo, "2007-04-05T14:30Z" o "2007-04-05T12:30−02:00" .
Se pueden usar formatos básicos o extendidos, pero tanto la fecha como la hora deben usar el mismo formato. La expresión de fecha puede ser de calendario, semanal u ordinal y debe utilizar una representación completa. La hora se puede representar utilizando un formato de precisión reducida específico.
Las duraciones definen la cantidad de tiempo intermedio en un intervalo de tiempo y están representadas por el formato P[n]Y[n]M[n]DT[n]H[n]M[n]S o P[n]W como se muestra a un lado. En estas representaciones, la [n] se reemplaza por el valor de cada uno de los elementos de fecha y hora que siguen a la [n]. No se requieren ceros a la izquierda, pero las partes comunicantes deben acordar el número máximo de dígitos para cada elemento. Las letras mayúsculas P , Y , M , W , D , T , H , M y S son designadores para cada uno de los elementos de fecha y hora y no se reemplazan.
Por ejemplo, "P3Y6M4DT12H30M5S" representa una duración de "tres años, seis meses, cuatro días, doce horas, treinta minutos y cinco segundos".
Los elementos de fecha y hora, incluido su designador, se pueden omitir si su valor es cero, y también se pueden omitir elementos de orden inferior para reducir la precisión. Por ejemplo, "P23DT23H" y "P4Y" son representaciones de duración aceptables. Sin embargo, al menos un elemento debe estar presente, por lo que "P" no es una representación válida durante 0 segundos. Sin embargo, "PT0S" o "P0D" son válidos y representan la misma duración.
Para resolver la ambigüedad, "P1M" es una duración de un mes y "PT1M" es una duración de un minuto (tenga en cuenta el designador de tiempo, T, que precede al valor de tiempo). El valor más pequeño utilizado también puede tener una fracción decimal, [39] como en "P0.5Y" para indicar medio año. Esta fracción decimal se puede especificar con una coma o un punto , como en "P0,5Y" o "P0.5Y". El estándar no prohíbe que los valores de fecha y hora en una representación de duración excedan sus "puntos de transferencia", excepto como se indica a continuación. Por lo tanto, se podría utilizar "PT36H" así como "P1DT12H" para representar la misma duración. Pero tenga en cuenta que "PT36H" no es lo mismo que "P1DT12H" al cambiar del horario de verano al horario de verano .
Alternativamente, se puede utilizar un formato de duración basado en representaciones combinadas de fecha y hora mediante acuerdo entre las partes comunicantes, ya sea en el formato básico PAAAAMMDDThhmmss o en el formato extendido P[AAAA]-[MM]-[DD]T[hh]: [mm]:[ss] . Por ejemplo, la primera duración que se muestra arriba sería "P0003-06-04T12:30:05" . Sin embargo, los valores individuales de fecha y hora no pueden exceder sus módulos (por ejemplo, no se permitiría un valor de 13 para el mes o 25 para la hora). [40]
El estándar describe una duración como parte de intervalos de tiempo, que se analizan en la siguiente sección. El formato de duración por sí solo es ambiguo con respecto al número total de días en un año calendario y mes calendario. El número de segundos en un día calendario también es ambiguo debido a los segundos intercalares . Por ejemplo, "P1M" por sí solo podría ser 28, 29, 30 o 31 días. No hay ambigüedad cuando se utiliza en un intervalo de tiempo. Usando el ejemplo "P2M" duración de dos meses calendario:
El formato de duración (o un subconjunto del mismo) se usa ampliamente independientemente de los intervalos de tiempo, como ocurre con la clase Duración de Java 8 que admite un subconjunto del formato de duración. [41] [42]
Un intervalo de tiempo es el tiempo intermedio entre dos puntos de tiempo. La cantidad de tiempo intermedio se expresa mediante una duración (como se describe en la sección anterior). Los dos puntos de tiempo (inicio y fin) se expresan mediante una representación combinada de fecha y hora o simplemente mediante una representación de fecha.
Hay cuatro formas de expresar un intervalo de tiempo:
De estos, los tres primeros requieren dos valores separados por un designador de intervalo que suele ser un sólido (más comúnmente conocido como barra diagonal "/"). La sección 3.2.6 de ISO 8601-1:2019 señala que "Un sólido puede ser reemplazado por un guión doble ["--"] por acuerdo mutuo de los socios comunicantes", y las versiones anteriores usaban notaciones como "2000--2002". . [43] El uso de un guión doble en lugar de un sólido permite la inclusión en los nombres de archivos de computadora ; [44] en los sistemas operativos comunes, un solidus es un carácter reservado y no está permitido en un nombre de archivo.
Para las expresiones <inicio>/<fin>, si falta algún elemento en el valor final, se supone que es el mismo que el valor inicial, incluida la zona horaria. Esta característica del estándar permite representaciones concisas de intervalos de tiempo. Por ejemplo, la fecha de una reunión de dos horas, incluidas las horas de inicio y finalización, podría mostrarse simplemente como "2007-12-14T13:30/15:30", donde "/15:30" implica "/2007-12- 14T15:30" (la misma fecha de inicio), o las fechas de inicio y finalización de un período de facturación mensual como "2008-02-15/03-14", donde "/03-14" implica "/2008-03 -14" (el mismo año del inicio).
Si se desea una mayor precisión para representar el intervalo de tiempo, entonces se pueden agregar más elementos de tiempo a la representación. Un intervalo denominado "2007-11-13/15" puede comenzar en cualquier momento el 2007-11-13 y finalizar en cualquier momento el 2007-11-15 , mientras que "2007-11-13T09:00/15T17:00" incluye los tiempos de inicio y fin. Para incluir explícitamente todas las fechas de inicio y finalización, el intervalo se representaría como "2007-11-13T00:00/16T00:00" .
Los intervalos de repetición se especifican en la cláusula "4.5 Intervalo de tiempo recurrente". Se forman agregando "R[n]/" al comienzo de una expresión de intervalo, donde R se usa como la letra misma y [n] se reemplaza por el número de repeticiones. Dejar de lado el valor de [n] o especificar un valor de -1 significa un número ilimitado de repeticiones. Un valor de 0 para [n] significa que el intervalo no se repite.
Si el intervalo especifica el inicio (formularios 1 y 2 anteriores), entonces este es el inicio del intervalo que se repite. Si el intervalo especifica el final pero no el inicio (formulario 3 anterior), entonces este es el final del intervalo que se repite. Por ejemplo, para repetir el intervalo de "P1Y2M10DT2H30M" cinco veces comenzando en "2008-03-01T13:00:00Z" , utilice "R5/2008-03-01T13:00:00Z/P1Y2M10DT2H30M" .
ISO 8601:2000 permitió el truncamiento (por acuerdo), donde se omiten los componentes principales de una fecha u hora. En particular, esto permitió utilizar años de dos dígitos, así como los formatos ambiguos AA-MM-DD y AAMMDD. Esta disposición fue eliminada en ISO 8601:2004.
Los ejemplos primero y séptimo dados anteriormente omiten el interlineado -de siglo. Otros formatos tienen un interlineado -por siglo, año, mes, semana, hora y minuto omitidos, según sea necesario para eliminar la ambigüedad del formato.
ISO 8601-2:2019 define un conjunto de extensiones estandarizadas para los formatos de fecha y hora ISO 8601.
En Internet , el World Wide Web Consortium (W3C) utiliza el estándar IETF basado en ISO 8601 para definir un perfil del estándar que restringe los formatos de fecha y hora admitidos para reducir la posibilidad de error y la complejidad del software. La especificación muy simple se basa en un borrador del RFC 3339 que se menciona a continuación. [45]
Varias especificaciones hacen referencia a ISO 8601, pero no siempre se utiliza toda la gama de opciones de ISO 8601. Por ejemplo, las diversas normas de guías electrónicas de programas para televisión, radio digital, etc. utilizan varias formas para describir puntos en el tiempo y duraciones. La especificación de metadatos de audio ID3 también utiliza un subconjunto de ISO 8601. [46] GeneralizedTime del estándar de codificación X.690 utiliza otro subconjunto de ISO 8601.
A partir de 2006, la fecha de la semana ISO aparece en su forma básica en los envases comerciales de las principales marcas en los Estados Unidos. [ cita necesaria ] Su apariencia dependía de la planta de envasado, enlatado o embotellado en particular más que de cualquier marca en particular. El formato es particularmente útil para el control de calidad, de modo que los errores de producción puedan rastrearse fácilmente.
IETF RFC 3339 [47] define un perfil de ISO 8601 para su uso en protocolos y estándares de Internet . Excluye explícitamente duraciones y fechas anteriores a la era común . No se permiten formatos más complejos, como números de semana y días ordinales. [48]
RFC 3339 se desvía de ISO 8601 al permitir que se especifique un desplazamiento de zona horaria cero como "-00:00", lo que ISO 8601 prohíbe. RFC 3339 pretende que "-00:00" tenga la connotación de que no indica una zona horaria preferida, mientras que el "+00:00" correspondiente o cualquier desplazamiento distinto de cero connota que se prefiere el desplazamiento que se utiliza. Esta convención con respecto a "-00:00" se deriva de RFC anteriores, como RFC 2822, que la utiliza para marcas de tiempo en encabezados de correo electrónico . [49] RFC 2822 no afirmó que ninguna parte de su formato de marca de tiempo se ajuste a ISO 8601, por lo que era libre de utilizar esta convención sin conflictos.
Anexo A: ... A partir de ese concepto se derivaron lógicamente las representaciones de todos los demás valores de fecha y hora;
por tanto, las normas ISO 2014, ISO 3307 e ISO 4031 han sido reemplazadas.
... La identificación de una fecha particular mediante fechas ordinales (ISO 2711) y mediante el sistema de numeración de semanas (ISO 2015) eran métodos alternativos que también podía abarcar el concepto básico de esta Norma Internacional;
por lo tanto, ISO 2015 e ISO 2711 ahora han sido reemplazadas.
El calendario gregoriano hoy sirve como estándar internacional para uso civil.
3.5 Ampliación... Por mutuo acuerdo de los socios en el intercambio de información, se permite ampliar el componente que identifica el año calendario, que de lo contrario se limita a cuatro dígitos.
Esto permite hacer referencia a fechas y horas en años calendario fuera del rango respaldado por representaciones completas, es decir, antes del inicio del año [0000] o después del final del año [9999].
Se permite la representación truncada, como se especifica en [ISO.8601.2000], Secciones 5.2.1.3 d), e) y f)., aunque eliminado en ISO 8601:2004
Se permite la representación truncada, como se especifica en [ISO.8601.2000], Secciones 5.2.1.3 d), e) y f).
4.2.2.4 ... la fracción decimal se dividirá de la parte entera por el signo decimal especificado en ISO 31-0, es decir, la coma [,] o punto [.].
De estos, la coma es el signo preferido.
Convención de compensación local desconocida: si se conoce la hora en UTC, pero se desconoce la compensación con la hora local, esto se puede representar con una compensación de "-00:00".
Esto difiere semánticamente de un desplazamiento de "Z" o "+00:00", lo que implica que UTC es el punto de referencia preferido para la hora especificada.
RFC2822 [IMAIL-UPDATE] describe una convención similar para el correo electrónico
En un entorno donde se utiliza un repertorio de caracteres basado en ISO/IEC 646, "guión" y "menos" se asignan a "guión-menos".
Las representaciones con un "más-menos" sólo se utilizarán en dicho entorno si el repertorio de intercambio incluye "más-menos"
4.3.2 NOTA: Por mutuo acuerdo de los socios en el intercambio de información, el carácter [T] podrá omitirse en aplicaciones donde no exista riesgo de confundir una representación de fecha y hora del día con otras definidas en esta Norma Internacional.
5.6.
NOTA: ISO 8601 define fecha y hora separadas por "T".
Las aplicaciones que utilizan esta sintaxis pueden optar, en aras de la legibilidad, por especificar una fecha completa y un tiempo completo separados por (digamos) un carácter de espacio.
b) Si es necesario para una aplicación particular, los componentes de menor orden podrán tener una fracción decimal.
Descripción general de la implementación