En octubre la Conferencia General de Pesas y Medidas vota una resolución que deja el UTC continuo a partir del 20 de mayo de 2027. Si pasa —y todo apunta a que sí—, no habrá más segundos intercalares durante muchísimo tiempo. La contrapartida: se permite que la diferencia entre el UTC y el UT1, la escala que sigue la rotación real del planeta, llegue a ser de hasta una hora.
Qué se vota exactamente
Hoy el UTC lo marcan relojes atómicos, y el segundo intercalar existe para que no se separe más de 0,9 segundos del tiempo que dicta el giro de la Tierra, que va a su bola. Desde que el sistema arrancó en 1972 se han añadido 27 segundos intercalares.
La prisa viene de que la rotación terrestre se ha acelerado ligeramente en los últimos años. Eso abre la puerta a algo que no se ha hecho nunca: quitar un segundo en lugar de añadirlo. Un grupo de expertos convocado por los organismos internacionales de tiempo estimó un 30 % de probabilidad de que haga falta un segundo intercalar negativo antes de 2035.
Setnam Shemar, científico principal del NPL británico, lo cuenta sin rodeos: casi todas las arquitecturas digitales y los servidores de tiempo en red están escritos dando por hecho que los segundos solo se suman.
"Perder un segundo podría provocar interrupciones graves en infraestructuras críticas", incluidas telecomunicaciones, red eléctrica y navegación por satélite.
De ahí la propuesta de ampliar el margen a una hora y quitarse el problema de encima. Shemar cree que la resolución saldrá adelante porque la mayoría de delegaciones nacionales llevan años queriendo cerrar el tema, y calcula que el desfase no llegaría a la hora completa antes de mil años. Si seguimos aquí para verlo, tendremos otras preocupaciones.
Por qué esto importa si construyes o mantienes software
El bug nunca fue el segundo: fue la resta
Los segundos intercalares positivos ya han tirado cosas. En el primer segundo de 2017, Cloudflare contó que parte de su DNS se cayó porque un cálculo de duración salió negativo: un instante posterior era "anterior" a otro, y el código no contemplaba ese caso. El segundo intercalar no rompió nada por sí mismo; rompió la suposición de que el tiempo avanza y las restas dan positivo.
Un segundo negativo es peor por un motivo muy concreto: ese camino de código no lo ha ejecutado nunca nadie en producción. Cero pruebas de campo en cincuenta años. Cuando lees en un daemon de tiempo el manejo del bit de aviso de segundo intercalar, la rama del "restar" es, en el mejor de los casos, teoría bien escrita.
Que esa posibilidad desaparezca del calendario es la mejor noticia de infraestructura del año, y casi nadie la va a celebrar porque el fallo que evita es invisible.
Qué haría yo distinto desde hoy
No hace falta esperar a 2027 para sacar algo de esto. Un repaso corto, por orden de rentabilidad:
- Mide duraciones con reloj monótono, no con la hora de pared.
CLOCK_MONOTONIC,System.nanoTime(),time.Sinceen Go. Si estás restando dos marcas de fecha para saber cuánto ha tardado algo, el segundo intercalar es el menor de tus problemas: te lo va a romper igual un ajuste de NTP o una máquina virtual que se suspende. - Asume que una duración puede salir negativa y decide qué hacer: tratarla como cero, avisar, reintentar. Lo que no vale es dividir entre ella.
- Busca los 86400 a pelo en el código. Cualquier cálculo que convierta días a segundos multiplicando es candidato a revisión, y no solo por esto: los cambios de horario ya te dan días de 23 y 25 horas.
- Mira cómo está montado tu tiempo de verdad. Qué clientes NTP hay, contra qué servidores, si alguien hace smearing (repartir el segundo a lo largo de horas) y si tus proveedores de nube y tus máquinas propias hacen lo mismo. Mezclar dos estrategias de segundo intercalar en el mismo clúster es la forma más tonta de tener nodos con relojes distintos.
- Revisa las alertas que dependen de la tabla de segundos intercalares. Esos ficheros tienen fecha de caducidad y hay demonios que se quejan cuando expira. A partir de 2027 la tabla se queda quieta para siempre; conviene que tu monitorización no interprete eso como "datos de tiempo obsoletos" y empiece a pitar sin motivo.
- Si usas zonas horarias basadas en TAI (las
right/de tzdata) o guardas instantes en escalas atómicas, apunta que dejan de crecer. No se rompe nada, pero cambia el supuesto.
Lo que de verdad pierdes: el UTC deja de ser un reloj de sol
Aquí está la letra pequeña que casi no se cuenta. Hasta ahora podías tratar el UTC como una aproximación al ángulo de rotación de la Tierra con menos de un segundo de error. A partir de mayo de 2027 eso deja de ser cierto por diseño: el desfase crecerá, lentamente pero sin volver atrás.
A quien apunta antenas, mueve telescopios, procesa efemérides o hace geodesia le toca separar explícitamente dos cosas que muchos sistemas mezclan: tiempo civil (UTC) y orientación de la Tierra (UT1). Y si recibes el valor DUT1 en algún formato de difusión de tiempo con un campo pensado para valores por debajo del segundo, ese campo se te queda pequeño en algún momento. No es urgente, pero es el tipo de cosa que conviene mirar cuando el sistema aún se puede tocar sin prisa.
Lo que no cambia
- Nada es oficial todavía. El voto es en octubre y la fecha de entrada en vigor, mayo de 2027. Hasta entonces el mecanismo actual sigue vigente sobre el papel, aunque no se ha añadido ningún segundo intercalar desde finales de 2016.
- No se elimina el problema: se aplaza. Se amplía la tolerancia de 0,9 segundos a una hora. Es un aplazamiento de siglos, que en ingeniería es como si fuera para siempre, pero la resolución no dice qué se hará al llegar al límite. Ese marrón es de otros.
- Tu reloj sigue siendo tu responsabilidad. El 99 % de los bugs de tiempo que me he encontrado no venían de segundos intercalares: venían de NTP mal configurado, de contenedores heredando relojes raros, de guardar fechas sin zona y de restar
datetimecon la mejor intención. - El UTC seguirá basado en relojes atómicos. Lo que se retoca es la regla de sincronía con la rotación, no la definición del segundo.
Si tienes sistemas donde el tiempo es crítico —facturación por intervalos, colas ordenadas por marca temporal, sincronización entre nodos— este es un buen momento para hacer ese repaso, precisamente porque no hay incendio. Cualquier duda me dices y lo vemos.
Un saludo, Vicente.