UTC

UTC (Tiempo Universal Coordinado) es el estándar de tiempo de referencia global. Todas las demás zonas horarias de uso común se definen como un desplazamiento de UTC — normalmente un número entero de horas, ocasionalmente media hora o cuarto de hora (India es UTC+5:30; Nepal es UTC+5:45). UTC en sí no observa el horario de verano.

UTC es mantenido por la Oficina Internacional de Pesas y Medidas (BIPM) y el Servicio Internacional de Rotación Terrestre y Sistemas de Referencia (IERS). Su ritmo de tick proviene de un promedio ponderado de relojes atómicos en más de 80 laboratorios de todo el mundo. Se han insertado segundos intercalares ocasionales (o, hipotéticamente, eliminados) para mantener UTC dentro de 0,9 segundos del tiempo solar. A partir de 2026, los segundos intercalares están programados para su depreciación en 2035.

UTC se confunde a menudo con GMT (Hora del Meridiano de Greenwich). Para la mayoría de los propósitos prácticos son idénticos — ambos representan la hora en el meridiano de Greenwich sin horario de verano. La diferencia técnica es que GMT está definido por la rotación de la Tierra (que es irregular) y UTC por relojes atómicos (que son regulares). Cuando el Reino Unido está en horario de verano observa BST (Hora de Verano Británica = UTC+1); GMT entonces no se usa como etiqueta de reloj aunque el nombre de zona horaria persiste.

Convierte entre UTC y cualquiera de las 28 principales zonas horarias con nuestro conversor de zona horaria, que usa la base de datos de zonas horarias IANA del navegador para resultados correctos respecto al horario de verano.

Por qué “UTC” en lugar de CUT o TUC:el acrónimo es un compromiso deliberado. Los angloparlantes querían “CUT” (Coordinated Universal Time); los francófonos querían “TUC” (Temps Universel Coordonné). La ITU y la BIPM acordaron UTC en 1970 como una ordenación neutra en el idioma que no coincide exactamente con ninguna expansión. La convención es escribir la abreviatura en mayúsculas independientemente de la ortografía utilizada en el texto circundante.

UTC en código — qué almacenar realmente:la regla operativa para cualquier sistema que maneja datos de múltiples zonas horarias es “almacenar en UTC, renderizar en local”. Las marcas de tiempo de la base de datos deben estar en UTC (PostgreSQL TIMESTAMP WITH TIME ZONEnormaliza a UTC internamente; MySQL TIMESTAMPhace lo mismo; MongoDB Datees UTC por especificación). Las capas de visualización convierten a la configuración regional del usuario en el momento del renderizado. Almacenar tiempos de reloj de pared locales sin información de zona es la fuente canónica de bugs de “la reserva se movió una hora después del horario de verano” y se considera universalmente un antipatrón. Referencia: BIPM — Tiempo Universal Coordinado (UTC).

Ejemplo práctico

Un usuario en Nueva York programa una reunión para “3:00 PM del 5 de noviembre de 2025”. El backend debería almacenar esto como un instante UTC. Nueva York está en EST (UTC−5) el 5 de noviembre (el horario de verano terminó el 2 de noviembre), por lo que el valor almacenado es 2025-11-05T20:00:00Z. Un segundo invitado en Berlín ve la misma reunión: Berlín está en CET (UTC+1) en esa fecha, por lo que el calendario muestra 2025-11-05 21:00 CET. Un tercer invitado en Tokio (UTC+9, sin horario de verano) ve 2025-11-06 05:00 JST — el mismo instante, diferentes relojes de pared, todos derivados de una sola marca de tiempo UTC almacenada. Ahora suponga que la reunión se repite semanalmente: almacenar “cada miércoles a las 20:00 UTC” se desplazaría silenciosamente para el usuario de Nueva York cuando terminara el horario de verano (esperaban las 3pm local, obtendrían las 4pm local después de la transición del 2 de noviembre). Los sistemas de calendario manejan esto almacenando los eventos recurrentes en la zona de origen con el nombre de zona IANA adjunto, expandiéndose a UTC solo en el renderizado.

Cuándo y por qué importa

Casi todos los bugs de “la reunión se movió”, “el informe se ejecutó a la hora incorrecta” o “el trabajo cron se ejecutó dos veces al cambiar el horario de verano” se deben a almacenar la hora local sin la zona o a almacenar el desplazamiento de zona (+01:00) en lugar del identificador de zona (Europe/Berlin). El desplazamiento está bien para un único instante pero se vuelve ambiguo para cualquier fecha futura — el identificador de zona preserva las reglas del horario de verano. Las reglas pragmáticas: almacenar instantes en UTC (o con zona explícita), almacenar fechas orientadas al usuario con identificadores de zona IANA (Europe/Berlin, no +01:00), nunca usar abreviaturas de zona de 3 letras (CST es ambiguo entre China, Cuba y el centro de EE. UU.), y dejar que una base de datos de zonas (tzdata vía IANA, actualizada trimestralmente) maneje la conversión. Referencia: Base de Datos de Zonas Horarias IANA.