El segundo adicional que las computadoras nunca fueron diseñadas para amar
Los relojes atómicos, la base de la medición del tiempo moderna, marcan el paso con una precisión inquebrantable. La rotación de la Tierra, sin embargo, es todo menos constante, acelerándose y desacelerándose de forma impredecible. Para reconciliar este desajuste, históricamente se han insertado leap seconds (segundos intercalares) en el Tiempo Universal Coordinado (UTC), manteniéndolo dentro de los 0.9 segundos del ritmo celestial del planeta.
Desde su introducción en 1972, se han añadido 27 segundos intercalares positivos. En estas raras ocasiones, el reloj avanza de las 23:59:59 a unas inéditas 23:59:60, antes de pasar finalmente a la medianoche. Este segundo adicional plantea un desafío único para los sistemas informáticos.
Unix time, una medida fundamental, asume esencialmente que cada día contiene exactamente 86,400 segundos, sin ofrecer una representación nativa para las 23:59:60. Los sistemas operativos como Linux tradicionalmente abordan esto repitiendo un segundo, retrasando efectivamente el reloj para reproducir las 23:59:59 dos veces.
Este ajuste de tiempo "no monótono", donde el tiempo del reloj de pared parece moverse momentáneamente hacia atrás, viola una suposición central en innumerables aplicaciones de software. Tales interrupciones han provocado repetidamente fallos críticos, incluida la infame caída de Reddit en 2012, destacando la fragilidad inherente de un sistema construido sobre un segundo que las computadoras nunca fueron diseñadas para amar.
Cómo un segundo repetido puso a Reddit de rodillas
Un ejemplo principal de esta cascada ocurrió el 30 de junio de 2012. Ese día, la inserción de un leap second provocó un error crítico en el kernel de Linux. En lugar de ajustarse correctamente, el código hrtimer del kernel, al interactuar con los temporizadores futex, provocó que los procesos se activaran repetida e instantáneamente. Esto llevó la utilización de la CPU al 100%, bloqueando efectivamente los sistemas.
Reddit, una importante plataforma en línea, sufrió las consecuencias de este sutil ajuste de tiempo. Sus servicios quedaron inaccesibles durante aproximadamente 30-40 minutos, lo que demuestra cómo un solo segundo repetido puede propagarse a través de la infraestructura de producción y poner de rodillas a una aplicación ampliamente utilizada.
Este incidente, y otros similares, destacaron una lección de ingeniería fundamental: el wall-clock time (tiempo de reloj de pared) no siempre es monótono. Puede saltar hacia adelante, retroceder o repetirse, desafiando la suposición implícita en gran parte del software de que el tiempo siempre progresa linealmente.
Para sistemas robustos, los desarrolladores deben diseñar la lógica para el tiempo transcurrido y el orden de los eventos de manera que no dependa ciegamente de time.Now(). En su lugar, deben tener en cuenta las posibles discontinuidades. Esto implica el uso de monotonic clocks (relojes monótonos) para medir duraciones y gestionar cuidadosamente las secuencias de eventos donde el tiempo puede parecer retroceder.
El pánico del tiempo negativo de Cloudflare y la solución de 'smear'
Un segundo intercalar diferente, el día de Año Nuevo de 2017, paralizó el DNS de Cloudflare. Su código en Go calculaba la duración de las consultas DNS restando una marca de tiempo de inicio de una marca de tiempo de finalización. Cuando el reloj retrocedió, el cálculo arrojó una duración negativa, que luego recibió una función que esperaba un argumento no negativo, lo que provocó un pánico fatal.
Este incidente puso de relieve un fallo fundamental: muchos sistemas de software asumen que el tiempo siempre avanza, una suposición que se ve vulnerada por el ajuste estándar del segundo intercalar. Como explicó Cloudflare, el "tiempo de resolución percibido será negativo", lo que provoca fallos inesperados. Para más detalles, consulte How and why the leap second affected Cloudflare DNS.
Para evitar saltos temporales tan bruscos, grandes operadores como Google y Meta emplean una técnica llamada leap smearing. En lugar de insertar un segundo completo de una vez, ralentizan sutilmente los relojes de sus sistemas durante varias horas, distribuyendo gradualmente el segundo adicional. Esto garantiza que el tiempo nunca parezca retroceder para sus sistemas internos.
El smearing evita la discontinuidad brusca que provoca que el software falle, pero introduce un nuevo desafío. Diferentes organizaciones pueden utilizar diferentes calendarios de smearing, lo que provoca que sus sistemas diverjan temporalmente en las lecturas de los relojes. Esto requiere una cuidadosa coordinación de las fuentes de tiempo para mantener la coherencia en toda la infraestructura distribuida.
¿Te está gustando? Recibe uno así en tu bandeja cada mañana.
un correo al día · date de baja en dos clics · sin rastreadores de terceros
Los segundos intercalares tienen los días contados, pero el tiempo sigue requiriendo atención
Los organismos internacionales de metrología han decidido eliminar el segundo intercalar, y el cambio entrará en vigor por completo antes o durante el año 2035. Este cambio monumental permite una mayor divergencia entre el Coordinated Universal Time (UTC) y el tiempo de rotación de la Tierra, poniendo fin a medio siglo de estos ajustes disruptivos. La decisión refleja un consenso creciente de que los riesgos superan a los beneficios.
Un factor crítico para este cambio es la reciente y ligera aceleración de la rotación de la Tierra. Esto planteó el espectro sin precedentes de un negative leap second, en el que habría que eliminar un segundo del UTC. Tal ajuste, nunca antes implementado, plantearía desafíos aún mayores para el software que históricamente ha tenido dificultades con la adición de un segundo.
Para los desarrolladores, esto significa que la amenaza inmediata de los segundos intercalares disminuirá eventualmente, pero los principios fundamentales de un cronometraje robusto permanecen. Utilice siempre monotonic clocks para medir duraciones y tiempos de espera, los cuales garantizan que el tiempo solo avance. Mantenga las marcas de tiempo civiles, a menudo vinculadas al UTC, separadas de las mediciones de tiempo transcurrido.
Por último, pruebe rigurosamente todas las suposiciones sobre el comportamiento del reloj. Incluso sin segundos intercalares, los sistemas pueden seguir encontrando:
- Fallos en la sincronización horaria
- Latencia de red
- Ajustes manuales del reloj
El diseño y la validación cuidadosos siguen siendo primordiales para sistemas distribuidos fiables.
Preguntas frecuentes
¿Qué es un segundo intercalar?
Un segundo intercalar es un segundo adicional que se añade ocasionalmente al UTC para mantenerlo aproximadamente alineado con la rotación irregular de la Tierra.
¿Por qué puede un segundo intercalar romper el software?
Algunos sistemas repiten o ajustan un segundo del reloj, lo que interrumpe el software que asume que el tiempo siempre avanza o que cada día tiene exactamente 86.400 segundos.
¿Qué causó el problema de DNS de Cloudflare en 2017?
Un ajuste hacia atrás del reloj produjo una duración negativa en el código que esperaba un valor no negativo, lo que provocó un error crítico en una función de números aleatorios.
¿Deberían los desarrolladores seguir usando monotonic clocks?
Sí. Utilice monotonic clocks para medir el tiempo transcurrido; los relojes de pared (wall clocks) aún pueden ajustarse y son más adecuados para marcas de tiempo y tiempo de calendario.