La ISO 8601 es una norma internacional que cubre el intercambio y la comunicación mundial de datos relacionados con la fecha y la hora . Es mantenida por 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] La norma proporciona un método bien definido e inequívoco para representar fechas y horas del calendario en las comunicaciones mundiales, especialmente para evitar la mala interpretación 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 ); horas , basadas en el sistema de cronometraje de 24 horas , con desplazamiento 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 especificado dentro de la norma (excluyendo así los nombres de años en el calendario chino ), o que no utilicen caracteres informáticos (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 tal manera que el término temporal más grande (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, los descriptores comunes de fechas (o partes de fechas) como "enero", "jueves" o "día de Año Nuevo" no están permitidos en las representaciones de intercambio dentro del estándar.
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 varios aspectos de la notación de fecha y hora: ISO 2014 , ISO 2015 , ISO 2711 , ISO 3307 e 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. La ISO 8601 fue preparada por, [4] y está bajo la responsabilidad directa del Comité Técnico ISO TC 154. [5]
La norma ISO 2014, aunque ya no es válida, es la que introdujo originalmente la notación de fecha completamente numérica en orden de mayor a menor importancia [AAAA]-[MM]-[DD] . El sistema de numeración de semanas de la ISO se introdujo en la norma ISO 2015, y la identificación de días por fechas ordinales se definió originalmente en la norma ISO 2711.
Publicada en febrero de 2019, [6] la cuarta revisión de la norma ISO 8601-1:2019 presenta contenidos ligeramente actualizados de la norma ISO 8601:2004 anterior, [7] [8] mientras que la nueva ISO 8601-2:2019 define varias extensiones como incertidumbres o partes del Formato de Fecha/Hora Extendido (EDTF). [9] [10] [11] [12] [13] [14]
En octubre de 2022 se publicó una enmienda que incluía pequeñas aclaraciones técnicas e intentaba eliminar ambigüedades en las definiciones. Sin embargo, el cambio más significativo 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]
La norma ISO 8601:2004 fija como fecha de referencia el calendario gregoriano del 20 de mayo de 1875 como fecha de la firma de la Convención del Metro en París ( la fecha de referencia explícita se eliminó en la norma ISO 8601-1:2019). Sin embargo, las fechas del calendario ISO anteriores a la convención siguen siendo compatibles con el calendario gregoriano desde su introducción oficial el 15 de octubre de 1582.
Las fechas anteriores, en el calendario gregoriano proléptico , pueden utilizarse por acuerdo mutuo de los socios que intercambian información. La norma establece que todas las fechas deben ser consecutivas, por lo que el uso del calendario juliano sería contrario a la norma (porque en la fecha de cambio, las fechas no serían consecutivas).
La norma 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 desde 0000 hasta 9999, siendo el año 0000 igual al 1 a. C. y todos los demás al 1 d. C. , de forma similar a la numeración astronómica . Sin embargo, la norma no permite automáticamente los años anteriores a 1583 (el primer año completo tras la introducción del calendario gregoriano ). En cambio, la norma establece que "los valores en el rango [0000] a [1582] solo 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 , el estándar también permite la expansión de la representación del año, pero solo mediante un acuerdo previo entre el remitente y el receptor. [21] Una representación de año expandida [± 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 estar precedida por un signo + o − [22] en lugar de la notación más común AD/BC (o CE/BCE ); por convención, 1 BC se etiqueta +0000 , 2 BC se etiqueta −0001, y así sucesivamente. [23]
Las representaciones de las fechas del calendario se presentan en el formato 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 como "19810405" en el formato básico .
La norma también permite escribir las fechas del calendario con precisión reducida. Por ejemplo, se puede escribir "1981-04" para significar "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 la norma permite tanto los formatos "AAAA-MM-DD" como AAAAMMDD para representaciones completas de fechas del calendario, si se omite el día [DD], solo se permite el formato AAAA-MM . Al no permitir fechas de la forma AAAAMM, la norma evita la confusión con la representación truncada [1] [3] AAAMMDD (que todavía se usa a menudo). La versión 2000 también permitía escribir el truncamiento "--04-05" para significar "5 de abril" [25] pero la versión 2004 no permite omitir el año cuando hay un mes.
Ejemplos:
Las representaciones de la fecha de la semana se encuentran en los formatos que se muestran en el cuadro adyacente. [AAAA] indica el año de numeración semanal ISO , que es ligeramente diferente del año del calendario gregoriano tradicional (ver a continuación). [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 , desde 1 hasta 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 cae en lunes, martes, miércoles o jueves, está en la semana 01. Si el 1 de enero cae en viernes, sábado o domingo, está en la semana 52 o 53 del año anterior (no existe la semana 00). El 28 de diciembre está siempre 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 semanal 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 brecha). Consta de 52 o 53 semanas completas. La primera semana ISO de un año puede tener hasta tres días que estén realmente en el año del calendario gregoriano que está terminando; 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 estén realmente en el año del calendario gregoriano que está comenzando; si son tres, son viernes, sábado y domingo. El jueves de cada semana ISO siempre está en el año del calendario gregoriano indicado por el año de numeración semanal 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 simple es preferible para 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 fechas, pero donde incluir un software de cálculo de calendario completo puede ser una molestia significativa. Este sistema a veces se conoce como "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 a partir del 1 de enero de 4713 a. C. Mediodía de Greenwich, calendario proléptico juliano (o mediodía en la fecha ISO −4713-11-24 que utiliza el calendario proléptico gregoriano con un año 0000).
La norma ISO 8601 utiliza el sistema de reloj de 24 horas . A partir de la norma 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 omitieron la T (que representa la hora) en ambos formatos.
Por lo tanto, una hora puede aparecer como "T134730" en el formato básico o como "T13:47:30" en el formato extendido . La norma 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 de los formatos de tiempo básico o extendido para lograr mayor brevedad pero menor precisión; los formatos de tiempo de precisión reducida resultantes son: [26]
A partir de la norma ISO 8601-1:2019/Amd 1:2022, se puede utilizar "00:00:00" para referirse a la medianoche correspondiente al instante del comienzo de un día calendario; y "24:00:00" para referirse a la medianoche correspondiente al instante del final de un día calendario. [1] La norma 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 añadir una fracción decimal al elemento de tiempo de orden más bajo presente en cualquiera de estas representaciones. Se utiliza un signo decimal , ya sea una coma o un punto en la línea base , 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 una preferencia excepto dentro de las Normas Internacionales, pero con una preferencia por una coma según ISO 8601:2004. [28] ) Por ejemplo, para indicar "14 horas, 30 minutos y medio", no incluya una cifra de segundos; represéntela como "14:30,5", "T1430,5", "14:30.5" o "T1430.5".
No existe límite en cuanto al número de decimales para la fracción decimal. Sin embargo, las partes que se comunican deben acordar el número de decimales. Por ejemplo, en Microsoft SQL Server, la precisión de una fracción decimal es 3 para un DATETIME, es decir, "aaaa-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 horaria, se supone que la hora es 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 . Por lo general, es preferible indicar una zona horaria (designador de zona) utilizando la notación del 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 UTC cero. 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 horaria ISO 8601 se denomina a veces "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 el UTC y deriva el "tiempo zulú" del tiempo medio de Greenwich [31] que se utilizaba anteriormente como el estándar de tiempo civil internacional. La comunidad científica ya no define con precisión el GMT y puede referirse tanto al UTC como al UT1 según el contexto. [32]
La diferencia horaria UTC se añade directamente a la hora en lugar del sufijo "Z" indicado anteriormente; no se utilizan otras letras de zona horaria náutica . La diferencia horaria se aplica a UTC para obtener la hora civil en la zona horaria designada en el formato '±[hh]:[mm]', '±[hh][mm]' o '±[hh]'.
Una diferencia horaria negativa con respecto al UTC describe una zona horaria al oeste del meridiano principal donde la hora civil está por detrás de la UTC. Por lo tanto, la designación de zona para Nueva York (en horario estándar ) sería "−05:00", "−0500" o "−05". Por el contrario, una diferencia horaria positiva con respecto al UTC describe una zona horaria al este del meridiano principal donde la hora civil está por delante de la UTC . Por lo tanto, la designación de zona para El Cairo será "+02:00", "+0200" o "+02".
Una zona horaria en la que la hora civil coincide con la UTC siempre se designa como positiva, aunque la diferencia sea cero (consulte las especificaciones relacionadas a continuación). Por lo tanto, 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 se permite indicar un valor cero de diferencia horaria con un signo negativo, como "−00:00", "−0000" o "−00". La sección que dicta el uso de los signos establece que se debe utilizar 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]
En contra de esta regla, el RFC 3339, que por lo demás es un perfil de la 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, la norma 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, 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 − MINUS SIGN en Unicode , entonces se debe utilizar ese carácter. La invocación de entidad de carácter HTML para − es −.
La norma ISO 8601-2:2019 permite duraciones generales para las diferencias horarias. Por ejemplo, se puede añadir más precisión a la diferencia horaria con el formato '<time>±[hh]:[mm]:[ss].[sss]' o '<time>±[n]H[n]M[n]S' como se muestra a continuación.
Un único punto en el tiempo puede representarse concatenando una expresión de fecha completa, la letra "T" como delimitador y una expresión de hora válida. Por ejemplo, "2007-04-05T14:30" . En la norma ISO 8601:2004 se permitía omitir el carácter "T" por mutuo acuerdo como en "200704051430" , [37] pero esta disposición se eliminó en la norma ISO 8601-1:2019. Separar partes de fecha y hora con otros caracteres como el espacio no está permitido en la norma ISO 8601, pero sí está permitido en su perfil RFC 3339. [38]
Si se requiere un indicador de zona horaria, este se coloca después de la fecha y la hora combinadas. Por ejemplo, "2007-04-05T14:30Z" o "2007-04-05T12:30−02:00" .
Se pueden utilizar formatos básicos o extendidos, pero tanto la fecha como la hora deben utilizar el mismo formato. La expresión de fecha puede ser de calendario, semana u ordinal, y debe utilizar una representación completa. La hora se puede representar utilizando un formato de precisión reducida especificado.
Las duraciones definen la cantidad de tiempo intermedio en un intervalo de tiempo y se representan con el formato P[n]Y[n]M[n]DT[n]H[n]M[n]S o P[n]W como se muestra al costado. 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 iniciales, pero las partes que se comunican 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 de 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, pueden omitirse si su valor es cero, y los elementos de orden inferior también pueden omitirse para reducir la precisión. Por ejemplo, "P23DT23H" y "P4Y" son representaciones de duración aceptables. Sin embargo, debe estar presente al menos un elemento, por lo que "P" no es una representación válida para una duración de 0 segundos. "PT0S" o "P0D", sin embargo, 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 (nótese 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 puede especificarse 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, "PT36H" podría usarse así como "P1DT12H" para representar la misma duración. Pero tenga en cuenta que "PT36H" no es lo mismo que "P1DT12H" cuando se cambia desde o hacia el horario de verano .
Como alternativa, se puede utilizar un formato de duración basado en representaciones combinadas de fecha y hora mediante acuerdo entre las partes que se comunican, ya sea en el formato básico PYYYYMMDDThhmmss o en el formato extendido P[YYYY]-[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 de fecha y hora individuales no pueden superar sus módulos (por ejemplo, no se permitiría un valor de 13 para el mes o de 25 para la hora). [40]
La norma 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 en relación con el número total de días de un año calendario y un mes calendario. El número de segundos de 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" de duración de dos meses calendario:
El formato de duración (o un subconjunto del mismo) se utiliza ampliamente independientemente de los intervalos de tiempo, como ocurre con la clase Duration de Java 8, que admite un subconjunto del formato de duración. [41] [42]
Un intervalo de tiempo es el tiempo transcurrido entre dos puntos de tiempo. La cantidad de tiempo transcurrido 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 solidus (más comúnmente conocido como una barra diagonal "/"). La sección 3.2.6 de la norma ISO 8601-1:2019 señala que "Un solidus puede reemplazarse por un guion doble ["--"] por mutuo acuerdo de los socios comunicantes", y las versiones anteriores usaban notaciones como "2000--2002". [43] El uso de un guion doble en lugar de un solidus permite la inclusión en 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.
En el caso de las expresiones <start>/<end>, si faltan elementos en el valor final, se supone que son los mismos que en 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, se podría mostrar como "2007-12-14T13:30/15:30", donde "/15:30" implica "/2007-12-14T15:30" (la misma fecha que el 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 que el inicio).
Si se desea una mayor precisión para representar el intervalo de tiempo, se pueden añadir 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 las horas de inicio y finalización. 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 añadiendo "R[n]/" al principio de una expresión de intervalo, donde R se utiliza como la letra en sí y [n] se reemplaza por el número de repeticiones. Si se omite el valor de [n] o se especifica un valor de -1, se obtiene 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), este es el inicio del intervalo de repetición. Si el intervalo especifica el final pero no el inicio (formulario 3 anterior), este es el final del intervalo de repetición. Por ejemplo, para repetir el intervalo de "P1Y2M10DT2H30M" cinco veces a partir de "2008-03-01T13:00:00Z" , utilice "R5/2008-03-01T13:00:00Z/P1Y2M10DT2H30M" .
La norma ISO 8601:2000 permitía el truncamiento (por acuerdo), en el que se omitían los componentes iniciales de una fecha u hora. Cabe destacar que esto permitía el uso de años de dos dígitos, así como los formatos ambiguos AA-MM-DD y AAMMDD. Esta disposición se eliminó en la norma ISO 8601:2004.
En los ejemplos primero y séptimo que se dan arriba se omite el interlineado -para el siglo. Otros formatos tienen un interlineado -para el siglo, año, mes, semana, hora y minuto que se omite, según sea necesario para desambiguar el formato.
La norma ISO 8601-2:2019 define un conjunto de extensiones estandarizadas para los formatos de fecha y hora ISO 8601.
En Internet , el Consorcio World Wide Web (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 mencionado a continuación. [45]
Varias especificaciones hacen referencia a la norma ISO 8601, pero no siempre se utiliza toda la gama de opciones de la norma ISO 8601. Por ejemplo, las distintas normas de guía electrónica 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 hace uso de un subconjunto de la norma ISO 8601. [46] El estándar de codificación X.690 GeneralizedTime hace uso de otro subconjunto de la norma ISO 8601.
A partir de 2006, la fecha de semana ISO aparece en su forma básica en los envases comerciales de las principales marcas en los Estados Unidos. [ cita requerida ] Su apariencia dependía de la planta de envasado, enlatado o embotellado en particular más que de una marca en particular. El formato es particularmente útil para el control de calidad, de modo que los errores de producción se puedan rastrear fácilmente.
La RFC 3339 de IETF [47] define un perfil de ISO 8601 para su uso en protocolos y estándares de Internet . Excluye explícitamente las duraciones y fechas anteriores a la era común . No se permiten los formatos más complejos, como los números de semana y los días ordinales. [48]
El RFC 3339 se desvía de la norma ISO 8601 al permitir que se especifique una diferencia horaria cero como "-00:00", algo que la norma ISO 8601 prohíbe. El RFC 3339 pretende que "-00:00" tenga la connotación de que no está indicando una zona horaria preferida, mientras que el "+00:00" o cualquier diferencia distinta de cero connota que la diferencia que se está utilizando es la preferida. Esta convención con respecto al "-00:00" se deriva de RFC anteriores, como el RFC 2822 que lo utiliza para las marcas de tiempo en los encabezados de correo electrónico . [49] El RFC 2822 no afirmó que alguna parte de su formato de marca de tiempo se ajuste a la norma ISO 8601, por lo que era libre de utilizar esta convención sin conflicto.
Basándose en los fundamentos de la RFC 3339, la IETF introdujo el formato de fecha y hora ampliado de Internet (IXDTF) en la RFC 9557. [50] Este formato amplía la representación de la marca de tiempo para incluir información adicional, como el nombre de una zona horaria asociada. La inclusión de nombres de zonas horarias es particularmente útil para aplicaciones que necesitan tener en cuenta eventos como las transiciones al horario de verano. Además, IXDTF mantiene la compatibilidad con la sintaxis preexistente para adjuntar nombres de zonas horarias a las marcas de tiempo, lo que proporciona un enfoque estandarizado y flexible para la representación de las marcas de tiempo en Internet. Ejemplo:
1996-12-19T16:39:57-08:00[America/Los_Angeles]
Anexo A: ... A partir de ese concepto se derivaron lógicamente las representaciones de todos los demás valores de fecha y hora; por lo tanto, se han reemplazado las normas ISO 2014, ISO 3307 e ISO 4031. ... La identificación de una fecha particular por medio de fechas ordinales (ISO 2711) y por medio del sistema de numeración de semanas (ISO 2015) eran métodos alternativos que el concepto básico de esta Norma Internacional también podía abarcar; por lo tanto, ahora se han reemplazado las normas ISO 2015 e ISO 2711.
El calendario gregoriano sirve hoy como estándar internacional para uso civil.
3.5 Expansión ... Por acuerdo mutuo de los socios en el intercambio de información, se permite expandir el componente que identifica el año calendario, que de otro modo está limitado a cuatro dígitos. Esto permite hacer referencia a fechas y horas en años calendario fuera del rango admitido por representaciones completas, es decir, antes del comienzo 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 se eliminó en la norma ISO 8601:2004
Se permite la representación truncada, tal 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 el punto [.]. De estos, la coma es el signo preferido.
Convención de desplazamiento local desconocido: si se conoce la hora en UTC, pero se desconoce el desplazamiento a la hora local, esto se puede representar con un desplazamiento de "-00:00". Esto difiere semánticamente de un desplazamiento de "Z" o "+00:00", que implican 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 en el que se hace uso de un repertorio de caracteres basado en ISO/IEC 646, tanto "guión" como "menos" se asignan a "guión-menos". Las representaciones con un "más-menos" solo se utilizarán en dicho entorno si el repertorio de intercambio incluye "más-menos"
4.3.2 NOTA: Por acuerdo mutuo de los socios en el intercambio de información, el carácter [T] puede 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, por razones de legibilidad, por especificar una fecha y hora completas separadas por (por ejemplo) un carácter de espacio.
b) Si es necesario para una aplicación particular, los componentes de orden más bajo pueden tener una fracción decimal.
Descripción general de la implementación