Lo confieso: no puedo evitar dedicar diez minutos a ver este vídeo de Tom Scott de Computerphile cada vez que me cruzo con él. Es un perfecto ejemplo de la complicación que en la práctica puede llegar a suponer algo aparentemente simple en el mundo de la programación. Estamos hablando de una de las mayores pesadillas surgidas de la combinación infernal entre el software y la historia de la humanidad: calcular la diferencia entre dos momentos en el calendario.
A pesar de una ligera sobreactuación, el protagonista de The Problem with Time & Timezones (El problema con la hora y la zonas horarias) parte de una cuestión sencilla:
Supongamos que estamos programando una aplicación y necesitamos calcular el tiempo exacto transcurrido entre un momento dado de un día y otro momento de una fecha diferente, quizá en un lugar distinto. ¿Qué habría que tener en cuenta para hacerlo correctamente?
Y así comienza el descenso a los infierno, paso a paso con todas las complicaciones que se conocen sobre el problema. Tan es así que su aparente calma inicial se torna en preocupación y llega prácticamente a la histeria a medida que la cosa se desmadra.
El vídeo no tiene subtítulos; así que para facilitar seguir la espectacular narración resumo aquí, con enlaces adicionales de bonus, las
Complicaciones a tener en cuenta al trabajar con fechas, horas y zonas horarias en programación
- La primera y más básica: tener en cuenta que en diferentes lugares del mundo hay diferentes zonas horarias y que para convertir las horas de unas a otras hay que sumar o restar consecuentemente. Lo normal es acceder a una enorme lista que en ocasiones tiene valores tan inusuales como «+9 horas y media» o «-5 horas y cuarto» (Ej. Australia) respecto al horario universal.
- En algunos países hay cambio horario de verano (y de invierno) pero en otros no. Así que hay que poder acceder a otra lista donde esa información esté disponible.
- A veces algunos países (ej. Samoa) pueden decidir saltarse un día viajando al futuro para cambiar de zona horaria.
- También en ciertas épocas (ej. II Guerra Mundial, Gran Bretaña) algunos países deciden tener doble horario de verano y adelantan o atrasan los relojes dos horas en vez de una.
- Y en ocasiones dentro del mismo país hay lugares con un horario diferente al de las zonas circundantes, por razones políticas, religiosas o cualquier otra. (Ej. Cisjordania).
- Si se trabaja con fechas «a largo plazo» es inevitable hablar del cambio del calendario juliano al gregoriano, en el que se repitieron 10 días, y de que ese cambio a partir de 1582 tuvo lugar en distintas fechas en distintos países, lo que hizo que en sitios como Suecia incluso existiera el día 30 de febrero de 1712. El cálculo obviamente no es fácil.
- O que a veces sucede como en 1751: que el año solo tuvo 282 días en vez de 365, para trasladar el «día de año nuevo» del 25 de marzo al 1 de enero actual.
- Desde el punto de vista más técnico, los científicos deciden a veces que es necesario añadir un segundo intercalar para compensar la «pérdida de tiempo» debida a los efectos gravitatorios de la Luna en la rotación de la Tierra. De modo que, ¡cuidado! ciertos días (generalmente el 30 de junio o el 31 de diciembre) duran «24 horas y un segundo». Esto puede ser un lío para ciertos procesos automatizados que requieren de gran precisión. En 2015 tendremos uno de estos el 30 de junio. Estos casos suponen tal trastorno técnico que hay quien pretende abolir este tipo de ajuste.
- Si además estamos hablando de programación también sucede que el tiempo Unix (número de segundo transcurridos desde las 00:00:00 UTC del 1 de enero de 1970) no incluye esos segundos intercalares, lo que produce una discontinuidad y una ambigüedad (ej. como ya sucedió en 1999), aunque si fuera necesario se puede corregir consultando una tabla adicional con los datos de los segundos intercalares.
- … porque imagina que estás haciendo mediciones astronómicas de alta precisión o algo parecido y al calcular la diferencia de tiempo entre dos eventos que has registrado añades sin saberlo uno, dos o diez segundos de error (!)
Como se puede ver la situación pasa de lo razonablemente difícil a lo muy complicado hasta caer en el pozo de la ambigüedad cuando se llega a ciertos requerimientos técnicos avanzados. Y todo debido a la forma tan peculiar que tenemos los humanos de gestionar el tiempo, los días del año y a cómo hemos modificado el calendario a lo largo de la historia.
Actualización: @sd nos envía un enlace a esta gran anotación de hace unos años, Falsehoods programmers believe about time (Falsedades que los programadores creen acerca del tiempo). Están algunas de las del vídeo y muchas otras también altamente interesantes.
