UTC, GMT, ISO 8601 y timestamp Unix: ¿cuál es la diferencia?

Te encuentras una y otra vez con el mismo momento, pero cada vez lleva ropa distinta. Un compañero dice «guárdalo todo en UTC». Una API te entrega "2026-07-16T09:00:00Z". Un archivo de configuración quiere GMT+8. Una columna de la base de datos guarda 1700000000. Una invitación de calendario dice 2026-07-16T17:00:00+08:00. Todos parecen decir «la hora», así que tratarlos como intercambiables parece seguro: leer el de la Z como GMT, quitarle el offset a la cadena del calendario, meter el valor de la API en la columna de timestamp sin convertir. Y entonces algo se desfasa ocho horas, o una reunión cae en el día equivocado la próxima primavera, y nadie ve por qué.

Aquí está el replanteamiento que lo alinea todo: estos no son cinco nombres de la misma cosa. Están en cuatro capas distintas, cada una responde una pregunta diferente. Uno es una escala de referencia: la línea contra la que se mide cada reloj. Uno es una zona horaria: una región con nombre cuyas reglas dicen a qué distancia de esa línea quedan sus relojes, y cuándo. Uno es un offset: el +HH:MM fijo que esas reglas producen en un instante concreto. Y dos son notaciones: formas de escribir un mismo instante, una como texto y otra como número. Confundirlos no es un desliz de vocabulario; es mezclar un patrón de medida, la regla que mide y la medición que resulta.

Este artículo ordena el montón en esas capas. Qué es UTC en realidad (una escala de referencia, no un lugar). Por qué GMT significa dos cosas distintas y no debería sustituir ni a UTC ni a «la hora del Reino Unido». La distinción que causa más bugs reales: una zona horaria como Asia/Shanghai frente al offset +08:00 que hoy produce, y las trampas GMT+8 / Etc/GMT+8 que viven en ese hueco. Qué es ISO 8601 (una forma de escribir, no una hora), cuándo sus cadenas se ordenan de verdad por tiempo, y qué significa la Z. Y por último, cómo encajan, para que «guárdalo en UTC», «dame una cadena ISO» y «1700000000» dejen de competir y describan un mismo instante desde ángulos distintos. Es el complemento de por qué un timestamp Unix da la hora equivocada: aquel iba sobre el número, este va sobre todos los nombres que lo rodean.

La única idea: cuatro capas, no cinco sinónimos

Reparte los términos en cuatro funciones y la confusión se disipa:

• La escala de referencia — UTC. Una línea acordada contra la que se define cada otro reloj. No es un lugar; el reloj de pared de nadie tiene que mostrarla.
• La zona horaria — Asia/Shanghai, Europe/London. Una región con nombre que arrastra una historia de reglas: sus offsets, sus cambios de horario de verano y cada modificación pasada de ellos. Viven en la base de datos de zonas horarias IANA.
• El offset — +08:00, -05:00, Z. Un número fijo de horas respecto a UTC en un instante: el valor que las reglas de una zona producen para un momento dado, no la zona en sí.
• Las notaciones — el texto ISO 8601 y el número del timestamp Unix. Dos formas de fijar un instante: ISO 8601 lo escribe como texto legible, el timestamp Unix/POSIX lo cuenta como un número. Una cadena ISO 8601 con Z o un offset numérico, y un timestamp Unix/POSIX, identifican un instante respecto a UTC.

Así que hay una referencia (UTC), zonas que arrastran reglas, los offsets que esas reglas producen en un instante, y dos maneras de escribir un momento. GMT es el único término que no tiene capa propia porque, como veremos, ha derivado entre dos de ellas.

UTC: la escala de referencia, no una zona en la que vives

UTC —Tiempo Universal Coordinado— es una escala de referencia, no una zona horaria. Es la línea maestra que el mundo acuerda usar para medir el tiempo, mantenida por un conjunto global de relojes atómicos y ajustada con algún segundo intercalar para que nunca se aleje demasiado de la rotación real de la Tierra. Cada hora civil del planeta se define como UTC más o menos un offset. (La sigla no sigue a propósito ni el orden inglés ni el francés: un compromiso de comité para que ningún idioma la «poseyera».)

Dos consecuencias importan para el código diario:

• Nadie tiene que mostrar UTC, pero todos pueden usar la misma referencia. Tokio marca UTC+9 en la pared, Chicago marca UTC−6 o −5, y ambos son el mismo instante expresado contra la misma referencia. Por eso «guarda los instantes confirmados en UTC» es buen consejo: es la única lectura sobre la que dos servidores, o dos usuarios, nunca discreparán. (Fíjate en «confirmados»: una cita local futura es la excepción, y ya veremos por qué.)
• UTC nunca observa el horario de verano (DST). Es una referencia fija; no adelanta. El DST es algo que añaden las zonas por encima. Así que cuando una hora UTC guardada parece «una hora desfasada en verano», UTC no se movió: se movió una conversión de zona.

Un apunte de contexto actual, ya que estamos en 2026: el propio esquema de segundos intercalares va a cambiar. En 2022 la Conferencia General de Pesas y Medidas resolvió elevar el margen permitido de UT1−UTC (la diferencia entre UTC y la rotación de la Tierra) en 2035 o antes, un cambio que se espera que elimine la necesidad de segundos intercalares regulares. Así que «el segundo intercalar ocasional» es un esquema que ya tiene fecha de cambio, no una ley eterna. En cualquier caso, el error que hay que jubilar: tratar UTC como «la hora de Londres» o «GMT». Es la línea desde la que se miden los relojes de pared, no uno de ellos.

GMT: una etiqueta, dos significados

GMT —Greenwich Mean Time— no es un sinónimo limpio de UTC, porque significa dos cosas distintas.

1. Históricamente, una escala de tiempo: el tiempo solar medio en el meridiano de Greenwich, ligado a la rotación de la Tierra (muy relacionado con lo que hoy se llama UT1). Fue la referencia del mundo desde la década de 1880 hasta que UTC, definida por relojes atómicos, tomó el relevo en los años setenta.
2. En el uso moderno cotidiano, una etiqueta de offset cero: un sustituto de UTC+00:00. Cuando alguien dice «14:00 GMT», casi siempre se refiere a UTC, y ambos coinciden con un margen muy por debajo de un segundo: suficiente cuando no te importa la precisión de sub-segundo.

Para logs y coordinación informal, leer «GMT» como UTC es inofensivo. Pero ten presentes dos precauciones:

• Para una referencia que ancle datos guardados, di UTC, no GMT: UTC es la escala moderna precisa; GMT es la palabra difusa que a veces significa una escala histórica y a veces una etiqueta de offset cero.
• «GMT» no es «la hora del Reino Unido» todo el año. El Reino Unido usa GMT en invierno, pero cambia a BST (British Summer Time, UTC+1) en verano. Así que en código, nunca codifiques GMT como sinónimo de Gran Bretaña: usa la zona IANA Europe/London, que sí conoce el BST; la etiqueta GMT nunca se mueve, pero el reloj de pared de Londres sí.

La que de verdad muerde: una zona horaria no es un offset

Esta es la distinción que vale la pena memorizar, porque es la fuente de los bugs de tiempo sutiles que llegan a producción. Asia/Shanghai y +08:00 no son dos formas de decir lo mismo: son dos capas distintas.

• Una zona horaria —Asia/Shanghai, Europe/Berlin, America/New_York— es una región con nombre y con toda una historia de reglas: su offset actual, si observa el horario de verano y cuándo, y cada cambio pasado de esas reglas. Estas reglas están en la base de datos de zonas horarias IANA que acompaña a tu sistema operativo y a tu runtime, y esa base se actualiza varias veces al año, a menudo porque un gobierno cambia sus relojes por decisión política; las reglas de una zona no están congeladas.
• Un offset —+08:00, -05:00, Z— es el resultado fijo que las reglas de una zona producen en un instante. Te dice cuánto por delante o por detrás de UTC estuvo un momento, y nada más.

Por qué la diferencia no es académica: un offset no puede decirte cuál será el offset en otro instante. Berlín es +01:00 en invierno y +02:00 en verano. Guarda un evento futuro como «el próximo marzo, 9:00 +01:00» y habrás congelado el offset de hoy sobre una fecha que puede caer después del cambio de primavera al DST, así que la reunión se desplazará una hora. Para guardar bien un evento local futuro debes conservar el nombre de la zona más la hora local (Europe/Berlin, 09:00), de modo que el offset se calcule con las reglas vigentes entonces. (Las zonas también hacen que algunas horas de reloj desaparezcan o se repitan en un cambio de DST —la hora de primavera que nunca ocurre, la de otoño que ocurre dos veces—, y eso es otra fuente de bugs de «una hora»; el artículo complementario recorre esos casos.)

En ese hueco viven tres trampas, y las tres son reales:

• GMT+8, +08:00 y Etc/GMT+8 no son la misma cadena. +08:00 es el offset ISO/RFC (ocho horas por delante de UTC). GMT+8 es una etiqueta informal que algunas librerías aceptan. Pero Etc/GMT+8 en la base IANA/POSIX tiene el signo invertido: significa UTC−8, no +8. Si echas mano de Etc/GMT+8 esperando Shanghái, acabarás en el Pacífico. Para el intercambio, prefiere +08:00; cuando necesites reglas, usa una zona real como Asia/Shanghai.
• Las abreviaturas de zona son ambiguas: no las parsees nunca. CST es la hora Central de EE. UU., y la hora estándar de China, y la de Cuba. IST es India, Israel e Irlanda. No llevan ningún offset fiable; trátalas como decoración de pantalla y guarda el nombre IANA.

Cuando necesites ver cómo cae un instante en varias zonas con nombre —con las reglas reales y el DST de cada una— para eso está un conversor de zonas horarias: resuelve la zona en vez de asumir un offset congelado.

ISO 8601: una forma de escribir, no una hora

ISO 8601 es un formato de texto para fechas y horas: una notación, no un reloj. Existe para que un momento escrito sea inequívoco entre idiomas y regiones, en vez del juego de adivinanzas de 03/04/05. Su forma:

2026-07-16T09:00:00Z          ← fecha, «T», hora y un designador de UTC
2026-07-16T17:00:00+08:00     ← el mismo instante, escrito con un offset

Las piezas que importan: la fecha es big-endian (YYYY-MM-DD), una T literal separa la fecha de la hora, y la parte que la gente olvida es la más importante: el designador final —una Z o un offset como ±HH:MM— es lo que ata el texto a la referencia. Sin él, la cadena es solo una fecha-hora local sin anclaje: la aplicación tiene que aportar la zona que falta, y un parser puede recurrir a una zona por defecto (a menudo la local del runtime) o rechazar el valor sin más. (Ese recurso silencioso a la hora local es exactamente el bug de «un día de desfase» del artículo complementario.)

Vale la pena corregir aquí una media verdad: «las cadenas ISO se ordenan cronológicamente como texto plano». Lo hacen, pero solo una vez normalizadas: mismo formato, misma precisión, campos con ceros a la izquierda y el mismo offset, idealmente todas convertidas a UTC Z. Mezcla offsets y el orden de texto deja de coincidir con el orden temporal: 2026-07-16T20:00:00+08:00 va después de 2026-07-16T13:00:00Z como texto, y sin embargo es el instante anterior (12:00Z frente a 13:00Z). Así que el superpoder «ordenable» es real, pero es una propiedad de las cadenas UTC normalizadas, no del texto ISO en general.

Dos notas más ahorran confusión. Primera: cuando una API dice «envía un timestamp ISO 8601», casi siempre se refiere a RFC 3339, el perfil de internet más estricto de ISO 8601 —fecha y hora completas y un offset obligatorio (Z o numérico)—. El ISO 8601 por sí solo también admite cosas que rara vez quieres en una API, como fechas por semana (2026-W29) y duraciones (P3DT4H). Segunda: Z y +00:00 son exactamente iguales: ambos dicen «offset cero, esto es UTC».

«Z» y «Zulu»: la pieza más pequeña

La Z al final de ...09:00:00Z es solo el designador de offset cero, es decir, UTC. Leída en voz alta en la aviación y el ámbito militar es «Zulu» —la palabra del alfabeto fonético para la letra Z—, así que oirás llamar a un instante «0900 Zulu». Z y +00:00 son las dos formas estándar de escribir el offset cero; «UTC» es el nombre en lenguaje llano de ese significado, no un sufijo que puedas añadir (2026-07-16T09:00:00UTC no es un timestamp válido). Los tres apuntan al mismo anclaje, pero solo dos son sintaxis. La única trampa es olvidar la Z y darla por supuesta: una cadena que debía llevarla y no la lleva no es UTC, es ambigua.

El número: el timestamp Unix (POSIX)

La columna que guarda 1700000000 es la otra notación: un instante escrito como conteo, no como texto. Conviene precisar sus reglas, porque hablar a la ligera de «el número del timestamp» es donde empieza la confusión de dígitos:

• El conteo arranca en el epoch Unix, 1970-01-01T00:00:00Z: anclado, como todo lo demás, a UTC.
• El tiempo POSIX se cuenta en segundos e ignora deliberadamente los segundos intercalares (cada día se trata como exactamente 86 400 segundos), lo que mantiene el número reversible a una fecha con aritmética simple.
• La unidad no es universal. 1700000000 son segundos (10 dígitos hoy); el Date.now() de JavaScript devuelve milisegundos (1700000000000, 13 dígitos); algunos sistemas usan microsegundos o nanosegundos. Pasar segundos a algo que espera milisegundos es el bug clásico sobre el que se construye el artículo complementario.

1700000000       segundos Unix/POSIX
1700000000000    milisegundos Unix (JavaScript)

Para moverte entre ese conteo y una fecha legible —y para comprobar si un valor está en segundos o milisegundos— un conversor de timestamps Unix se encarga de esa conversión.

Cómo encajan de verdad

Representa un mismo instante de todas estas formas y las capas dejan de competir:

instante:     un momento concreto
timestamp:    1700000000                    (segundos, contados desde la referencia UTC)
ISO 8601 (Z): 2023-11-14T22:13:20Z          (texto, anclado a UTC)
ISO 8601 (+): 2023-11-14T14:13:20-08:00     (mismo instante; el offset que produjo Los Ángeles ese día)
zona:         «Asia/Shanghai» → 06:13 del día siguiente en el reloj de pared

Cada línea es el mismo momento. El número del timestamp y las dos cadenas ISO son tres notaciones de él; las reglas de la zona producen el offset que lo convierte de vuelta al reloj de pared de alguien; UTC es la referencia en la que todas se apoyan. Por eso el consejo por capas es coherente y no contradictorio: «guárdalo en UTC» significa mantener el instante anclado a la referencia —un número de timestamp o una cadena con Z lo hacen—; «dame una cadena ISO» pide la notación de texto; «conviértelo a la zona del usuario» ocurre una vez, al mostrar, usando las reglas de la zona.

Las decisiones, en un solo lugar

Casi todas las preguntas reales se reducen a qué persistir. Esta tabla cubre casi todas (y un artículo aparte profundiza en elegir entre un timestamp entero y una cadena ISO, y qué tipo de columna nativo usar):

Dos hábitos hacen que la tabla se sostenga. Primero, «guárdalo todo en UTC» es casi correcto pero demasiado amplio: guarda los instantes confirmados en UTC, pero guarda las agendas locales futuras como hora local más una zona IANA, o un cambio de reglas las moverá en silencio. Segundo, cuando los términos se difuminen, pregúntate en qué capa estás —referencia, zona, offset o notación— y la respuesta suele salir sola.

El hilo conductor, y el lazo de vuelta al número en sí: UTC es la escala de referencia; una zona horaria arrastra las reglas; un offset es lo que esas reglas producen en un instante; y el conteo del timestamp y la cadena ISO son dos formas de escribir ese instante. Una vez que cada término tiene una capa, «UTC vs GMT vs ISO 8601» deja de ser un versus: nunca estuvieron respondiendo la misma pregunta.

Referencias

• Resolución 4 de la CGPM (2022): sobre el uso y el desarrollo futuro de UTC — la decisión de elevar el límite de UT1−UTC en 2035 o antes.
• Base de datos de zonas horarias IANA — la fuente autorizada de nombres y reglas de zona.
• RFC 3339: fecha y hora en internet — el perfil de internet estricto de ISO 8601.
• Formato de fecha y hora ISO 8601 — la propia norma ISO.