Fin del Segundo Intercalar en 2027: Qué Cambia en UTC y en Tu Código

Hola HaWkers, el 15 de octubre de 2026, en Versalles, la 28.ª Conferencia General de Pesas y Medidas (CGPM) aprobó la resolución que pone fin al segundo intercalar. A partir del 20 de mayo de 2027, el Tiempo Universal Coordinado (UTC) pasa a correr de forma continua, sin ese segundo extra que, desde 1972, se insertó 27 veces en el reloj oficial del planeta.

Parece una noticia de astronomía, y lo es. Pero quien ya vio un servidor colgarse a medianoche de un 30 de junio sabe que el segundo intercalar siempre fue un problema de software. ¿Tu sistema todavía arrastra algún parche pensado para él? En este artículo vas a entender qué decidió la CGPM, por qué la rotación de la Tierra forzó la decisión, qué bugs famosos causó el segundo extra y, sobre todo, qué revisar en tu código y en tu infraestructura antes de mayo de 2027.

Qué es el Segundo Intercalar y Por Qué Existía

El mundo tiene dos formas de medir el tiempo. Una es atómica: el segundo se define por la oscilación del átomo de cesio, y el Tiempo Atómico Internacional (TAI) es el promedio de cientos de relojes atómicos repartidos por el planeta. La otra es astronómica: el UT1 sigue la rotación real de la Tierra, que no es perfectamente regular.

El UTC es el punto medio entre las dos. Avanza al ritmo de los relojes atómicos, pero se mantenía a menos de 0,9 segundos del UT1. Cada vez que la diferencia se acercaba a ese límite, el Servicio Internacional de Rotación de la Tierra y Sistemas de Referencia (IERS) anunciaba, en su Boletín C, que se añadiría un segundo a finales de junio o de diciembre. El reloj marcaba entonces 23:59:60 antes de cambiar de día.

Algunos números para ubicarse:

• 1972: año del primer ajuste, cuando la diferencia entre TAI y UTC se fijó en 10 segundos.
• 27: total de segundos intercalares insertados desde entonces, todos positivos.
• 37 segundos: diferencia actual entre TAI y UTC.
• 31 de diciembre de 2016: fecha del último segundo intercalar aplicado.

Fíjate en el último punto. Hace casi diez años que no se añade ningún segundo, y eso tiene explicación.

Por Qué la Decisión Llegó Ahora: La Tierra Está Girando Más Rápido

Durante décadas, la Tierra giró un poco más despacio que el reloj atómico, y por eso todos los ajustes fueron para añadir tiempo. En los últimos años, la tendencia se invirtió: la rotación se aceleró ligeramente. Un artículo de Duncan Agnew publicado en la revista Nature en marzo de 2024 proyectó que sería necesario quitar un segundo alrededor de 2029, y un taller de 2025 del comité consultivo de tiempo y frecuencia con el IERS estimó en un 30% la probabilidad de un segundo intercalar negativo antes de 2035.

Nunca se ha aplicado un segundo negativo. Ningún sistema en producción se probó de verdad con un minuto de 59 segundos, y el historial de los segundos positivos muestra que la industria apenas aguantaba el caso "fácil".

La trayectoria de la decisión fue esta:

1. Noviembre de 2022: la 27.ª CGPM decidió abolir el segundo intercalar antes de 2035, sin fijar la fecha.
2. Enero de 2026: el borrador de la Resolución C propuso el 20 de mayo de 2027 como fecha de inicio.
3. 15 de octubre de 2026: la 28.ª CGPM aprobó la resolución "sobre las acciones técnicas necesarias para garantizar la continuidad del UTC".

La nueva regla permite que la diferencia entre UTC y UT1 crezca hasta 3.600 segundos, es decir, una hora. En la práctica, los especialistas estiman que no hará falta ninguna corrección durante mucho tiempo, así que el límite funciona como precaución. El BIPM, el IERS y los servicios de distribución de tiempo trabajan ahora en la transición de mayo de 2027.

Los Bugs Que el Segundo Intercalar Dejó en la Historia

Si trabajas con infraestructura, probablemente ya oíste hablar de al menos uno de estos casos.

Reddit y el Kernel Linux en 2012

El 30 de junio de 2012, Reddit estuvo caído entre 30 y 40 minutos. La causa fue un bug en el subsistema de temporizadores de alta resolución (hrtimer) del kernel Linux: el cambio de hora confundió al kernel, y las máquinas se colgaron con la CPU al 100%. El mismo segundo tumbó o degradó servicios de varias empresas esa noche.

Cloudflare y Go en 2017

En el paso de 2016 a 2017, el servidor DNS de Cloudflare (RRDNS, escrito en Go) calculó un tiempo de respuesta negativo después de que el reloj retrocediera un segundo. Ese valor terminó en rand.Int63n(), que entra en pánico con un argumento negativo. En el pico, cerca del 0,2% de las consultas DNS fallaron, y la corrección tardó 6 horas y 45 minutos en distribuirse. Poco después, Go 1.9 empezó a incluir un reloj monotónico en el runtime, para que las diferencias de tiempo nunca más fueran negativas cuando el reloj de pared retrocede.

El Parche Que se Volvió Estándar: el "Smear"

Para no lidiar con un 23:59:60, las grandes nubes empezaron a repartir el segundo extra a lo largo de varias horas. Google lo hace desde 2008: durante 24 horas, de mediodía a mediodía en UTC, los relojes corren 11,6 partes por millón más despacio. AWS adoptó el mismo esquema de 24 horas, y Meta usa una ventana de 17 horas.

El problema es que cada empresa lo reparte a su manera. Durante la ventana, un reloj "repartido" puede estar hasta medio segundo lejos del UTC oficial, y dos servidores que usan fuentes de tiempo distintas no coinciden entre sí. Para quien compara timestamps de sistemas diferentes, esto es una fuente silenciosa de inconsistencia.

Qué Hace Tu Código con 23:59:60

Lo primero que conviene saber es que la mayoría de los lenguajes simplemente no representa el segundo 60. El tiempo Unix cuenta segundos como si todos los días tuvieran exactamente 86.400, y las bibliotecas estándar siguen esa ficción. Pruébalo tú mismo en Node.js:

// Node.js 24: cómo maneja Date el segundo intercalar de 2016

// Un string ISO con el segundo 60 no se acepta: el resultado es NaN
const parsed = Date.parse('2016-12-31T23:59:60Z');
console.log(parsed); // NaN

// En cambio, Date.UTC acepta 60 segundos, pero "desborda" al minuto siguiente
const overflow = new Date(Date.UTC(2016, 11, 31, 23, 59, 60));
console.log(overflow.toISOString()); // 2017-01-01T00:00:00.000Z

// Conclusión: el segundo intercalar desaparece de tu sistema.
// Si un log externo trae "23:59:60", trátalo antes de parsear.
function parseWithLeapSecond(iso) {
  const leap = iso.replace(/T(\d{2}):(\d{2}):60/, 'T$1:$2:59.999');
  return new Date(leap);
}

console.log(parseWithLeapSecond('2016-12-31T23:59:60Z').toISOString());
// 2016-12-31T23:59:59.999Z

Python es todavía más directo: datetime.fromisoformat('2016-12-31T23:59:60+00:00') lanza ValueError: second must be in 0..59. Si consumes datos de equipos, satélites o sistemas financieros que registran el segundo 60, ese error ya puede estar escondido en algún pipeline de ingesta.

Con el fin del segundo intercalar, este caso deja de aparecer en datos nuevos a partir de 2027. Los datos históricos, sin embargo, siguen ahí. Si procesas logs o series temporales antiguas, el tratamiento de arriba sigue siendo necesario.

Mide la Duración con Reloj Monotónico, Siempre

La lección más importante del caso de Cloudflare no depende del segundo intercalar. El reloj de pared (Date.now(), time.time(), System.currentTimeMillis()) puede retroceder o saltar por varios motivos: ajuste de NTP, corrección manual, suspensión de VM, migración de máquina. Medir duración con él es un bug esperando a ocurrir.

// Mal: Date.now() es reloj de pared y puede ir hacia atrás
function measureWrong(fn) {
  const start = Date.now();
  fn();
  return Date.now() - start; // puede ser negativo si se ajusta el reloj
}

// Bien: performance.now() es monotónico, solo avanza
function measureRight(fn) {
  const start = performance.now();
  fn();
  return performance.now() - start;
}

// En Node.js, para precisión de nanosegundos, usa process.hrtime.bigint()
function measureNs(fn) {
  const start = process.hrtime.bigint();
  fn();
  return process.hrtime.bigint() - start; // BigInt en nanosegundos
}

console.log(`${measureRight(() => JSON.stringify({ a: 1 })).toFixed(3)} ms`);

En Python, la regla es la misma: time.monotonic() o time.perf_counter() para duraciones, time.time() solo para registrar cuándo ocurrió algo. En Go, desde la versión 1.9, time.Since(start) ya usa la lectura monotónica incluida en time.Time, siempre que no elimines esa lectura con operaciones como t.Round(0) o la serialización.

El fin del segundo intercalar reduce los saltos previstos en el reloj de pared, pero no elimina los demás. El código que mide duración con reloj monotónico no se ve afectado por ninguno de ellos.

Dónde Vive el Segundo Intercalar en Tu Infraestructura

El segundo intercalar no aparece solo en el código de aplicación. Vive en tres lugares que merecen una revisión.

1. El Archivo leap-seconds.list

La base de datos de zonas horarias (tzdata) y el IERS distribuyen el archivo leap-seconds.list, que incluye cada ajuste y una fecha de expiración. Varios daemons de NTP y PTP leen este archivo, y algunos se quejan cuando expira. Este script lee el archivo y muestra el desfase actual entre TAI y UTC:

# Lee leap-seconds.list y muestra el desfase TAI-UTC y la validez
from datetime import datetime, timezone
from pathlib import Path

# Época de NTP (1900-01-01) respecto a la época Unix (1970-01-01)
NTP_TO_UNIX = 2_208_988_800

def ntp_to_datetime(ntp_seconds: int) -> datetime:
    return datetime.fromtimestamp(ntp_seconds - NTP_TO_UNIX, tz=timezone.utc)

def read_leap_seconds(path: str):
    entries, expires = [], None
    for line in Path(path).read_text().splitlines():
        if line.startswith('#@'):
            # Línea especial con la fecha de expiración del archivo
            expires = ntp_to_datetime(int(line.split()[1]))
        elif line and not line.startswith('#'):
            ntp, offset = line.split()[:2]
            entries.append((ntp_to_datetime(int(ntp)), int(offset)))
    return entries, expires

entries, expires = read_leap_seconds('/usr/share/zoneinfo/leap-seconds.list')
last_date, offset = entries[-1]
print(f'Último ajuste: {last_date:%Y-%m-%d} | TAI-UTC = {offset}s')
print(f'Archivo válido hasta: {expires:%Y-%m-%d}')

La ruta cambia según el sistema (en Debian y Ubuntu suele estar en /usr/share/zoneinfo/). La salida esperada hoy es TAI-UTC = 37s, con el último ajuste el 1 de enero de 2017. Después de mayo de 2027, ese número debería congelarse en 37 para siempre.

2. El Daemon de NTP

Si usas chrony, que es el estándar en varias distribuciones, la configuración de cómo reaccionar ante un segundo intercalar está en chrony.conf. Es un buen momento para saber qué haría tu servidor:

# /etc/chrony/chrony.conf (fragmento)

# Cómo tratar un segundo intercalar anunciado:
#   system -> deja que el kernel inserte el segundo (por defecto)
#   slew   -> reparte el ajuste, sin salto en el reloj
#   step   -> da el salto de una vez
#   ignore -> no hace nada
leapsecmode slew

# Velocidad máxima de corrección en ppm (1000 ppm corrige 1 s en ~17 min)
maxslewrate 1000

# Lee los segundos intercalares de tzdata, útil si la fuente NTP no los anuncia
leapsectz right/UTC

Y para comprobar el estado actual en la máquina:

# chrony muestra "Leap status: Normal" cuando no hay ningún ajuste pendiente
chronyc tracking | grep -i leap

# En systemd, comprueba si el reloj está sincronizado
timedatectl show --property=NTPSynchronized

Un cuidado importante: no mezcles fuentes de tiempo con y sin smear en el mismo clúster. Si la mitad de las máquinas usa el servidor de tiempo de tu nube (con smear) y la otra mitad usa pool.ntp.org (sin smear), no van a coincidir durante cualquier ajuste. Con el fin del segundo intercalar este riesgo disminuye, pero el hábito de estandarizar la fuente de tiempo vale para siempre.

3. Sistemas Que Dependen de Escalas Distintas

GPS, Galileo y otros sistemas de navegación usan escalas de tiempo propias, sin segundos intercalares. El tiempo GPS, por ejemplo, va 19 segundos por detrás del TAI, lo que hoy da 18 segundos de diferencia respecto al UTC. Cualquier software que convierte entre estas escalas tiene una tabla de ajustes en algún sitio. Después de 2027 la tabla deja de crecer, pero no se puede borrar: los timestamps antiguos siguen necesitándola.

Qué Se Vuelve Más Simple (y Qué No Cambia) Después de 2027

Se vuelve más simple:

• Ya no habrá 23:59:60 en datos nuevos ni anuncios de ajuste cada seis meses.
• Las estrategias de smear dejan de ser necesarias, y los relojes de distintas empresas dejan de divergir por su culpa.
• El riesgo del primer segundo intercalar negativo, que nunca se probó en producción, sale de la mesa.
• La cuenta "todos los días tienen 86.400 segundos", que el tiempo Unix siempre fingió que era verdad, pasa a ser verdad para el UTC de aquí en adelante.

No cambia:

• Las zonas horarias y el horario de verano siguen existiendo y siguen cambiando por decisión política. Ese siempre fue el mayor problema de las fechas en software, y el fin del segundo intercalar no lo toca.
• Los datos históricos con segundos intercalares siguen exigiendo tratamiento.
• El reloj de pared puede seguir saltando por NTP, VM o error humano. La duración se sigue midiendo con reloj monotónico.
• Astrónomos, operadores de satélites y quien necesita el UT1 siguen teniendo que aplicar la diferencia por su cuenta, y esta va a crecer despacio.

Para quien trabaja con fechas en JavaScript, el cambio combina bien con la llegada de la Temporal API, que separa de forma explícita instantes, fechas de calendario y zonas horarias. Si todavía no la has visto, expliqué cómo funciona en Temporal API en ES2026: la nueva forma de manejar fechas en JavaScript.

Un Checklist Rápido Para Revisar Antes de Mayo de 2027

Nada de esto es urgente, pero todo es barato de comprobar:

1. Busca en el código mediciones de duración hechas con Date.now(), time.time() o equivalentes y cámbialas por un reloj monotónico.
2. Verifica si algún parser de logs o de datos de terceros se rompe con :60 en el campo de segundos.
3. Averigua qué fuente de tiempo usa cada entorno (nube, pool.ntp.org, servidor interno) y estandarízala.
4. Revisa las configuraciones de chrony o ntpd con reglas específicas para el segundo intercalar y documenta el motivo de cada una.
5. Mantén el paquete tzdata actualizado: sigue recibiendo cambios de zona horaria, que son mucho más frecuentes que los segundos intercalares.
6. Si conviertes entre GPS, TAI y UTC, asegúrate de que la tabla de ajustes está versionada y de que nadie la va a "limpiar" pensando que es código muerto.

Perspectivas: El Reloj Mundial Eligió la Previsibilidad

La decisión de la CGPM es, en el fondo, una elección de ingeniería. Durante más de 50 años, el reloj oficial del planeta intentó seguir la rotación de la Tierra con una precisión de menos de un segundo, y el precio lo pagó toda la infraestructura digital, un bug tras otro. Con la Tierra amenazando con exigir el primer segundo negativo de la historia, el riesgo se volvió demasiado alto.

A partir del 20 de mayo de 2027, el UTC pasa a ser previsible: cada día tiene el mismo número de segundos y ningún reloj necesita saltar por culpa del cielo. La diferencia con la rotación real va a crecer despacio, y algún día, quizá dentro de siglos, alguien tendrá que decidir qué hacer con ella. Hasta entonces, el mensaje para quien escribe software es simple: trata las fechas como datos delicados, mide la duración con reloj monotónico y no confíes en que el reloj de pared siempre avanza.

¡Vamos con todo! 🦅

📚 ¿Quieres Seguir lo Que Viene Por Delante?

Este artículo cubrió el fin del segundo intercalar en 2027 y lo que cambia en UTC y en tu código, pero el ecosistema cambia cada semana y no todo se convierte en artículo aquí.

En X comparto lo que estoy probando, el detrás de escena de los proyectos y las novedades que aparecen antes de convertirse en post.

Sígueme Allá

👉 Seguir a @jeffbruchado en X

💡 Contenido diario sobre desarrollo, carrera y las herramientas que realmente uso