¡Adiós a los “leap seconds”! — Lo que necesitas saber antes de 2035
Introducción
El Bureau International des Poids et Mesures (BIPM) acaba de confirmar que, a partir de 2035, los leap seconds desaparecerán de forma definitiva. La noticia ha disparado las búsquedas en Google Trends y ha encendido los foros de Hacker News, Reddit y los grupos de TI especializados.
Si tu empresa depende de sincronización de tiempo —bolsas de valores, plataformas de cripto‑trading, sistemas de navegación o infraestructuras críticas— este cambio no es opcional: tendrás que adaptar tus relojes, tus scripts de NTP y, en muchos casos, el firmware de tus dispositivos GPS. En este artículo te explicamos qué son los leap seconds, por qué su supresión es importante ahora, y, lo más valioso, una hoja de ruta práctica con auditorías, scripts y check‑lists para que tu organización esté lista antes del 1 de enero 2035.
Preguntas frecuentes
1️⃣ ¿Qué pasa con los sistemas que todavía usan leap seconds cuando se elimina la inserción?
| Situación | Consecuencia |
|---|---|
| El software sigue leyendo la tabla de leap‑second del IERS | Funciona mientras la tabla se actualice. |
| La tabla deja de recibir actualizaciones | El reloj se desincroniza ≈ 1 s por leap second omitido. En entornos críticos eso se traduce en timestamps erróneos, fallos en firmas digitales y pérdida de correlación de eventos. |
Recomendación práctica
-
Audita todos los sistemas que consumen la tabla de leap seconds (
/var/lib/ntp/leap-seconds.list,leap-seconds.listdechrony, etc.). - Desactiva la dependencia de la tabla y pasa a una fórmula estática (ver sección 2).
2️⃣ ¿Cómo afecta a los dispositivos GPS?
- GPST (Tiempo de Satélite) está adelantado respecto a UTC + 18 s (a 2024).
- Cuando se eliminen los leap seconds, la diferencia Δ entre GPST y UTC quedará fija.
Ejemplo: si hoy GPST = UTC + 18 s, después de 2035 seguirá siendo GPST = UTC + 18 s para siempre.
Qué hacer
- Identifica los receptores que convierten GPST → UTC mediante tablas de leap seconds.
- Actualiza el firmware para que use la constante Δ en lugar de buscar la tabla.
-
Prueba la conversión con el siguiente comando (Linux,
gpsd):
gpspipe -w | jq '.class=="TIME" and .time' | head -n 5
# Verifica que la hora UTC mostrada coincide con la esperada (+18 s)
3️⃣ ¿Qué riesgos corren los mercados financieros y los exchanges de criptomonedas si NTP/PTP no se adapta?
- Timestamps de alta precisión son obligatorios (MiFID II, SEC, etc.).
- Un desfase de 1 s puede provocar:
- Out‑of‑order trades.
- Fallos en la reconciliación de libros.
- Sanciones regulatorias.
En redes PTP (Precision Time Protocol) la falta de ajuste genera jitter y pérdida de alineación de paquetes, lo que afecta la latencia y, en casos extremos, lleva a caídas de servicios críticos.
Acciones inmediatas
# 1. Verifica la versión del daemon NTP/Chrony
ntpd -v # NTP
chronyd -v # Chrony
# 2. Forzar una sincronización con una fuente que ya no envíe leap seconds
sudo ntpdate -u -b time.cloudflare.com
# 3. En PTP, comprueba el offset estático
pmc -u -b 0 "GET OFFSET"
# Si el offset ≠ 0, ajusta el parámetro `clockClass` en el archivo de configuración
Hoja de ruta práctica
| Paso | Acción | Herramienta / Script | Comentario |
|---|---|---|---|
| 1. Inventario | Lista todos los servidores, routers, switches y dispositivos GPS que usan NTP/Chrony/PTP. | ansible-playbook inventory.yml |
Usa etiquetas time-sync:true. |
| 2. Auditoría de leap‑seconds | Busca archivos de tabla y configuraciones que dependan de ellos. | grep -R "leap‑seconds" /etc /var/lib |
Marca los que requieren cambio. |
| 3. Prueba de impacto | Simula la ausencia de leap seconds durante 30 días. | docker run --rm -v /etc/ntp.conf:/etc/ntp.conf ntp:latest -x |
Observa desviaciones en logs. |
| 4. Actualiza NTP/Chrony | Cambia a modo no‑leap (tinker panic 0 en ntp.conf) o usa chrony.conf con leapsectz off. |
bash\nsed -i '/^tinker/d' /etc/ntp.conf\necho 'tinker panic 0' >> /etc/ntp.conf\n
| Evita que el daemon falle por falta de tabla. |
| 5. Firmware GPS | Programa la actualización del firmware de los receptores. | Vendor‑specific OTA (ej. gps-upgrade -f firmware.bin) | Verifica la constante Δ después del flash. |
| 6. PTP | Configura clockClass y clockAccuracy para que el offset sea constante. | ptp4l -i eth0 -m -f /etc/ptp4l.conf | Usa max_offset 0 para bloquear drift. |
| 7. Monitoreo continuo | Implementa alertas si el offset supera 10 ms. | Prometheus + node_exporter + regla alert: TimeDrift. | Notifica al equipo de SRE. |
| 8. Documentación | Crea un run‑book con pasos de verificación post‑corte. | Markdown en el repo de documentación. | Incluye ejemplos de logs y comandos. |
Conclusiones
- La eliminación de los leap seconds es inevitable y se hará oficial en 2035.
- No adaptar tus sistemas provocará desincronizaciones de hasta 1 s, con consecuencias graves en finanzas, criptomonedas y telecomunicaciones.
- La solución es simple: eliminar la dependencia de tablas dinámicas, fijar la diferencia entre GPST y UTC, y validar que NTP/Chrony/PTP mantengan un offset constante.
Actúa ahora: realiza el inventario, ejecuta los scripts de auditoría y planifica la actualización de firmware antes de que el 1 de enero 2035 sea una fecha límite.
Check‑list rápido (para imprimir)
- [ ] Inventario completo de dispositivos de sincronización.
- [ ] Eliminada la referencia a
leap‑seconds.listen todos los daemons. - [ ] Firmware GPS actualizado a la versión que usa Δ constante.
- [ ] Configuración de NTP/Chrony en modo no‑leap.
- [ ] PTP con
clockClassymax_offsetajustados. - [ ] Alertas de drift < 10 ms activas en el sistema de monitoreo.
- [ ] Run‑book de validación post‑corte creado y probado.
Con estos pasos tu organización estará preparada para la nueva era del tiempo sin leap seconds. ¡No dejes que el reloj te pille desprevenido!
Herramienta mencionada: GitHub Copilot
Top comments (0)