Un 'Leap Second' (segundo intercalar o segundo bisiesto) es una corrección de un segundo que se inserta o, teóricamente, se elimina (aunque nunca ha ocurrido) en el Tiempo Universal Coordinado (UTC). Su propósito es mantener la diferencia entre UTC, que se basa en relojes atómicos estables, y UT1 (Tiempo Universal 1), que se basa en la rotación astronómica de la Tierra, dentro de 0.9 segundos. Dado que la rotación de la Tierra no es perfectamente uniforme y tiende a ralentizarse ligeramente con el tiempo, los 'Leap Seconds' son necesarios para evitar que la hora civil se desvíe significativamente de la posición aparente del Sol en el cielo.
La implementación de 'Leap Seconds' en el mundo real se gestiona a través de la autoridad internacional IERS (International Earth Rotation and Reference Systems Service), que anuncia estos eventos con meses de antelación. Sistemas operativos como Linux y Windows, así como servicios de sincronización de tiempo como NTP (Network Time Protocol), deben manejar estos eventos. Por ejemplo, en Linux, el kernel puede ser configurado para insertar el 'Leap Second' automáticamente, o los servicios NTP pueden distribuirlo. Grandes proveedores de servicios en la nube como Google, Amazon (AWS) y Microsoft Azure han desarrollado sus propias estrategias, a menudo optando por un 'smear' o 'leap smear', donde el segundo adicional se distribuye gradualmente a lo largo de un período de tiempo (ej. 24 horas) para evitar un salto discreto que podría causar problemas en sistemas distribuidos.
Para un arquitecto de sistemas, los 'Leap Seconds' son cruciales por los desafíos que plantean a la sincronización y consistencia de datos en sistemas distribuidos. Un 'Leap Second' puede causar que los relojes de los sistemas se comporten de manera inesperada, como repetir un segundo o saltar un segundo, lo que puede llevar a inconsistencias en logs, problemas en la ordenación de eventos (especialmente en sistemas que dependen de marcas de tiempo precisas para la causalidad o la replicación), y fallos en aplicaciones con lógica de temporización estricta. La decisión de cómo manejar los 'Leap Seconds' (ej. 'smear' vs. salto discreto) tiene implicaciones significativas en la complejidad de la infraestructura, la resiliencia del sistema y la compatibilidad con estándares externos. Un arquitecto debe evaluar el impacto en la lógica de negocio, los sistemas de monitoreo y las bases de datos, y diseñar soluciones que sean robustas frente a estas anomalías temporales, priorizando la consistencia o la disponibilidad según los requisitos del negocio.