Formato de fecha y hora ISO 8601 explicado
ISO 8601 es el estándar internacional para representar fechas y horas como cadenas. Su forma canónica — 2024-03-15T14:30:00Z — es inequívoca, ordenable y compatible con todos los lenguajes y bases de datos modernos. Esta guía cubre el formato componente a componente, el subconjunto RFC 3339 que la mayoría de las API usa en realidad, la nueva extensión de zona RFC 9557, y las variantes para duraciones, intervalos y fechas de semana.
¿Qué es ISO 8601?
ISO 8601 es la representación de fechas y horas de la Organización Internacional de Normalización. La versión actual (ISO 8601-1:2019 / -2:2019) define un formato de texto compacto, ordenado y neutral respecto al idioma. Todo su propósito es eliminar la ambigüedad: una fecha como 03/04/2024 es el 4 de marzo en EE. UU. y el 3 de abril en gran parte de Europa, pero 2024-03-04 significa lo mismo en todas partes. El estándar también es la base de RFC 3339, el perfil que la mayoría de los protocolos de internet usa en realidad.
- Orden año-mes-día, siempre: 2024-03-15 (no 03/15/2024 ni 15/03/2024)
- Parte de hora separada por una T literal o un espacio: 2024-03-15T14:30:00
- Zona explícita: Z para UTC, o ±HH:MM para un desfase
- Ordenable como texto — el orden lexicográfico coincide con el cronológico
El formato canónico de fecha-hora
La forma más común se parece a 2024-03-15T14:30:00.123Z. Cada componente es de ancho fijo y con ceros a la izquierda, y eso es lo que hace el formato ordenable e inequívoco.
| Componente | Ejemplo | Significado |
|---|---|---|
| YYYY | 2024 | Año de cuatro dígitos |
| MM | 03 | Mes de dos dígitos (01–12) |
| DD | 15 | Día de dos dígitos (01–31) |
| T | T | Separador fecha/hora (RFC 3339 también permite un espacio) |
| hh:mm:ss | 14:30:00 | Hora de 24 h, con ceros a la izquierda |
| .fff | .123 | Segundos fraccionarios opcionales (precisión arbitraria en ISO 8601) |
| Z o ±hh:mm | Z | Designador de zona (Z = UTC = +00:00) |
Designadores de zona horaria
Las zonas de ISO 8601 se codifican como desfases respecto a UTC, nunca como abreviaturas de zona tipo EST o CET (que son ambiguas). La cadena lleva suficiente información para reconstruir el instante UTC exacto, incluidos los desfases de media hora y de 45 minutos que usan algunas regiones.
| Designador | Desfase respecto a UTC | Zona de ejemplo |
|---|---|---|
| Z | +00:00 | UTC (hora "Zulú") |
| +09:00 | 9 horas por delante | Hora estándar de Japón |
| -05:00 | 5 horas por detrás | Hora estándar del Este (EE. UU.) |
| +05:30 | 5,5 horas por delante | Hora estándar de la India |
| +05:45 | 5,75 horas por delante | Hora estándar de Nepal |
| (ninguno) | sin especificar | Hora local — ambigua; evítala en API |
ISO 8601 vs RFC 3339
RFC 3339 es un perfil de ISO 8601 — más restrictivo y más fácil de analizar. La mayoría de los protocolos de internet (API JSON, HTTP, especificaciones IETF) apuntan específicamente a RFC 3339, así que cuando una API dice "ISO 8601" casi siempre se refiere al subconjunto RFC 3339. Las diferencias son pequeñas pero deciden si una cadena dada se analiza.
| Característica | ISO 8601 | RFC 3339 |
|---|---|---|
| Separador fecha/hora | T, u omitido en el formato básico | T o un solo espacio (obligatorio) |
| Desfase de zona | Opcional | Obligatorio |
| Segundos fraccionarios | Precisión arbitraria | Permitidos, limitados por el analizador |
| Formato básico (sin guiones) | 20240315T143000Z permitido | No permitido |
| Fechas de semana/ordinales | Permitidas | No permitidas |
| Uso típico | Archivos, hojas de cálculo, intercambio | API JSON, HTTP, especificaciones IETF |
RFC 9557: las zonas y la extensión Temporal
Un desfase simple como +01:00 te dice el instante pero no la zona — y los desfases cambian con el horario de verano, así que la misma zona es +01:00 en invierno y +02:00 en verano. RFC 9557 (2024) cierra esa brecha con el Internet Extended Date/Time Format (IXDTF): añade el nombre de zona IANA entre corchetes, como en 2024-03-15T14:30:00+01:00[Europe/Paris]. Es el formato de cadena que la API Temporal de JavaScript lee y escribe, así que lo verás más a medida que crezca la adopción de Temporal. Sigue siendo retrocompatible — quita el sufijo entre corchetes y tienes un timestamp RFC 3339 normal.
- Solo desfase: 2024-03-15T14:30:00+01:00 — el instante, pero no la zona
- IXDTF (RFC 9557): 2024-03-15T14:30:00+01:00[Europe/Paris] — instante más zona
- Retrocompatible: la etiqueta entre corchetes la pueden ignorar los analizadores RFC 3339
Variantes: duraciones, intervalos, fechas de semana
ISO 8601 cubre más que instantes. Varias variantes aparecen con regularidad en sistemas de planificación, archivo y generación de informes:
- Duraciones: P3Y6M4DT12H30M5S = 3 años, 6 meses, 4 días, 12 horas, 30 minutos, 5 segundos
- Intervalos: 2024-01-01/2024-02-01, o 2024-01-01/P1M (inicio + duración)
- Fechas ordinales: 2024-075 = el día 75 de 2024 (15 de marzo)
- Fechas de semana: 2024-W11-5 = viernes de la semana ISO 11 de 2024
- Intervalos repetidos: R3/2024-01-01/P1D = tres intervalos de un día desde el 1 de enero
ISO 8601 en el código
Todo lenguaje habitual puede producir y analizar el subconjunto RFC 3339 de fábrica. El hábito más seguro es emitir en UTC con una Z y volver a analizar hacia un instante, dejando cualquier conversión de zona para la capa de visualización.
- JavaScript emitir: new Date().toISOString() // '2024-03-15T14:30:00.123Z'
- JavaScript analizar: new Date('2024-03-15T14:30:00Z') // subconjunto RFC 3339
- Python emitir: datetime.now(timezone.utc).isoformat()
- Python analizar: datetime.fromisoformat('2024-03-15T14:30:00+00:00') // ISO completo en 3.11+
- La mayoría de las bases de datos (Postgres, SQLite) aceptan y devuelven ISO 8601 timestamptz directamente
Errores comunes en ISO 8601
Incluso con un estándar estricto, el código de análisis y emisión comete el mismo puñado de errores:
- Omitir la zona: 2024-03-15T14:30:00 sin Z ni desfase es ambiguo
- Usar "+0000" en lugar de "+00:00" — algunos analizadores lo aceptan, RFC 3339 no
- Usar una T que no es letra (los sosias Unicode se copian mal)
- Mezclar AM/PM de 12 h en ISO 8601 — siempre es de 24 h
- Truncar segundos fraccionarios sin redondear — elige una precisión y mantenla
- Tratar ISO 8601 como dependiente de la configuración regional — no lo es; el formato es fijo sea cual sea el idioma
Referencias relacionadas
FAQ
- ¿"2024-03-15 14:30:00Z" es ISO 8601 válido?
- Sí — el espacio entre la fecha y la hora está permitido en ISO 8601 (y en RFC 3339). La forma con T es preferible para un análisis por máquina inequívoco.
- ¿Qué significa la Z al final?
- Z significa UTC (desfase +00:00). Es la abreviatura de "hora Zulú", el alfabeto fonético OTAN/aviación para la letra Z.
- ¿Cómo analizo ISO 8601 en JavaScript?
- new Date("2024-03-15T14:30:00Z") funciona para el subconjunto RFC 3339 estándar. Para una compatibilidad ISO 8601 más amplia, usa una biblioteca como date-fns o la API Temporal.
- ¿ISO 8601 es lo mismo que RFC 3339?
- No — RFC 3339 es un subconjunto estricto. Todo timestamp RFC 3339 es ISO 8601 válido, pero no todo timestamp ISO 8601 es RFC 3339 válido.
- ¿Qué es RFC 9557?
- RFC 9557 (2024) amplía RFC 3339 con el Internet Extended Date/Time Format (IXDTF). Añade el nombre de zona IANA entre corchetes — por ejemplo 2024-03-15T14:30:00+01:00[Europe/Paris] — y sustenta el formato de cadena que usa la API Temporal de JavaScript.
- ¿Es obligatorio el separador T?
- En ISO 8601 estricto, la T puede omitirse en el formato básico; RFC 3339 exige una T o un solo espacio. Para el análisis por máquina, incluye siempre la T.
- ¿Cuál es la diferencia entre ISO 8601 e ISO 8601-2?
- ISO 8601-1 cubre la representación básica de fechas y horas. ISO 8601-2 (la extensión de 2019) añade construcciones nuevas como fechas inciertas, valores cualificadores e intervalos complejos.