El tiempo y los sistemas informáticos

Ante una nueva modificación al horario de invierno en Chile, nuevamente vuelvo a escuchar pequeños y grandes errores respecto a cómo se maneja el tiempo y hora en los sistemas informáticos. Estuve buscando algún artículo que explicara bien el tema en completitud, pero no lo encontré. La idea de este artículo es cubrir esta necesidad.

Me interesa hablar de los siguientes temas:

1. Muchos sistemas no están preparados para trabajar con distintas zonas horarias. En un mundo globalizado, creo que es inaceptable.
2. Peor aún, creo que ninguno contempla las (irremediables) modificaciones a los cambios de hora arbitrarios.
3. El tiempo de referencia oficial no es GMT, sino que UTC.
4. Existen minutos con más de 60 segundos (y eventualmente con 59 segundos).
5. NTP no tiene nada que ver con el cambio de hora, la zona horaria ni el horario de invierno/verano.
6. Los sistemas deben dejar de usar el formato DD/MM/YY.
7. Este es un problema aún no resuelto, pero se puede mejorar en varios aspectos.

Si le asombra una o más de las sentencias de arriba, lo invito a seguir leyendo.

El tiempo, unidad de medida continua y regular

El primer supuesto que toma la mayoría de sistemas informáticos es que el tiempo es completamente continuo y uniforme en todo el universo. Esto no es cierto (ya tendremos problemas cuando los viajes espaciales se hagan habituales), pero por ahora asumiremos esto.

Al tomar el tiempo de esta forma, podemos suponer que en cualquier parte del mundo es la misma hora. Podemos definir una “hora universal“. Cada país puede tener su hora oficial en referencia a la hora universal, y es lo que nos permite coordinar una reunión en Chile a las 09:00 hrs por la mañana con gente en Finlandia a las 14:00 hrs en la tarde. ¡Fácil y bonito! ¿No?

Bueno, no tanto, pues ahora comienzan las complicaciones…

Es UTC, no GMT… por favor

Variación día solar medio (fuente: Wikipedia)

Desde 1880+ la hora universal era calculada en base al tiempo solar medio. Esto es: se observa astronómicamente cuánto demora la tierra en dar una vuelta completa sobre si misma. Ese tiempo lo dividimos en 86400 segundos y ya está, tenemos hora oficial con la cual todos podemos sincronizarnos. Esto es lo que se conoce como GMT, pues es la hora en el meridiano de Greenwich.

El problema es que el tiempo solar medio es bastante irregular, no es para nada una medida estable. Si observan el gráfico, en general cada año la tierra gira mas lento y los días se van alargando, pero hay distintos fenómenos que modifican la velocidad en ambos sentidos (por ejemplo, los terremotos).

Esta variación en la medida de tiempo es inaceptable para muchas aplicaciones y sistemas. ¡Imaginen tener que parchar continuamente sus sistemas para redefinir el largo de un segundo!

Desde 1972, GMT es reemplazado por un nuevo estándar de tiempo universal: UTC que en inglés reza “Coordinated Universal Time” y en francés: “Temps Universel Coordonné”. O sea, no lograron ponerse de acuerdo en las siglas.

En UTC el largo de un segundo siempre es el mismo, pues está basado en relojes atómicos. Esto es muy ventajoso, nos permite tener muchos sistemas sincronizados con muy poco error, incluso a la milésima de segundo. Ya no es necesario ajustar los sistemas a los caprichos del tiempo solar medio. ¡Menos mal!

Lo relevante es que hoy en día UTC es el tiempo universal usado como referencia por todos los países. Esto es importante por las triquiñuelas que tiene, veamos.

Segundos intercalares o en sintonía con la tierra

En UTC tenemos segundos (y milisegundos, microsegundos, etc) estables. El problema de tener un segundo estable es que la tierra cada vez gira mas lento. A lo largo de los años, las 12:00pm de nuestro sistema informático será muy distinta a las 12:00pm astronómica. UTC resuelve esto haciendo que la duración de los minutos, horas y días sea variable.

Bueno, la mayoría de los días tiene 86400 segundos, pero hay días que tienen 1 segundo adicional. El último minuto, de la última hora del día en vez de 60 puede tener 61 segundos, y este segundo extra es llamado “segundo intercalar” (leap second en inglés). Es decir, el 31 de Diciembre de 2008 a las 23:59:60 UTC es una fecha válida.

No es tan raro si piensan que tenemos algo muy parecido con los días: Febrero 29 para los años bisiestos.

Puedes ver una lista de los segundos que han sido agregados en wikipedia, ya van 24 a la fecha. Como recordarán, la tierra cambia de velocidad irregularmente, no es algo que se pueda pre-calcular. Luego, se han agregado segundos intercalares arbitrariamente según observaciones astronómicas del movimiento de la tierra. También está contemplado que existan minutos con menos de 60 segundos, por si se diera el caso que la tierra gire más rápido, cosa que no ha ocurrido.

Ejemplo de segundo intercalar (Wikipedia)

Notar en la imagen que el segundo adicional es agregado a las 23:59:59 de la hora universal, pero localmente el segundo adicional será a medio día, a las 4 de la tarde, etc dependiendo de tu zona horaria.

Esto tiene enormes implicancias en los sistemas informáticos. Por ejemplo, si tu aplicación suma 60*60*24*30 segundos para decir “30 días a partir de hoy” lo estás haciendo mal, el resultado puede caer en el día 29 si te topas con el segundo adicional.

Es por esto que siempre debes utilizar un API que maneje segundos, días, meses y años “gregorianos“. Por favor, no lo hagas tú manualmente. Y espera, que el manejo del tiempo se complica más. Aún no terminamos.

Sincronizando el tiempo

El siguiente problema a resolver es cómo mantener nuestros sistemas sincronizados, esto es, con la misma hora y con la menor diferencia posible. Para esto existe el protocolo NTP (Network Time Protocol), el cual consiste en servidores que dan la hora y clientes que intentan sincronizarse con dichos servidores.

Si bien esto parece trivial, no lo es. De partida, la latencia variable en internet hace que los paquetes lleguen desordenados y varios milisegundos después (una vuelta completa desde Chile a EE.UU es al menos 150ms). El protocolo NTP debe compensar este hecho. Luego, es más complicado que copiar la hora de un servidor a otro (¡como muchos lo hacen!), pues el error se amplifica rápidamente.

Tal vez encuentres que un segundo no es tanto y para qué tanto escándalo. Pero hay muchas, demasiadas aplicaciones que no funcionan bien si no tienes relojes muy, muy bien sincronizados. Y en el resto, lo deseable es que la diferencia sea a lo más de unos 100 milisegundos. Si eres un administrador de sistemas, querrás por muchas razones tener los servidores y dispositivos con la misma fecha y hora.

El tema es tan importante, que el cliente NTP no llega y copia la hora del servidor. Sucede que el reloj de tu computador no es tan exacto comparado con un reloj atómico, por lo que tiene un error (supongamos -10 milisegundos cada 30 días). Entonces, el cliente NTP lo que hace es calcular ese error.

Puedes programar que tu computador inunde de consultas el servidor NTP y copie la hora (esto se llama SNTP), pero tendrás una precisión muy, muy mala y no es lo recomendado.

NTP stratum (fuente: Wikipedia)

Tal vez te estás preguntado cómo los servidores principales mantienen la hora tan bien. Los computadores que están conectados directamente a un reloj atómico están en Stratum 0. Luego están los servidores NTP conectados a ellos, y son Stratum 1. Y luego los servidores que consultan a los anteriores, que son Stratum 2 y etcétera.

Lo ideal es que tengas en tu datacenter un servidor NTP que hable directamente con ntp.shoa.cl (la hora oficial en Chile), y luego todos tus servidores/computadores/etc se conectan a este servidor. Tendrás diferencias muy pequeñas dentro de tu red y no saturarás al servidor oficial.

Por último, el protocolo NTP sólo da la hora universal (UTC, incluyendo segundos intercalares). Pero NTP no tiene nada que ver con la hora local de tu país ni si estamos en el horario de verano. Este problema lo veremos a continuación.

La hora en el mundo

Hasta ahora tenemos una hora oficial (UTC), correcciones arbitrarias (segundos intercalares) y un mecanismo de sincronización (NTP). Podemos definir distintas zonas horarias respecto a la hora universal UTC.

Zonas Horarias según base de datos TZ (fuente: Wikipedia)

Debemos considerar que las zonas horarias están definidas por límites políticos y no por el meridiano que nos corresponda. La diferencia horaria se escoge antojadizamente y no tiene relación con la “real”. En el caso de Chile, por longitud estamos dentro de la zona UTC-5, pero la hora estándar en Chile continental es UTC-4. Hay países que tienen más de una zona horaria: por ejemplo, Chile tiene además hora insular UTC-6, México tiene 3 zonas, etc.

Hoy en un mundo globalizado, una gran mayoría de sistemas informáticos almacenan y trabajan la hora en formato UTC. Esto garantiza que un evento se pueda mostrar en distintas zonas horarias del mundo. Por ejemplo, si tenemos una reunión el Lunes 9 de Mayo de 2011 a las 09:00 am CLT (UTC-4), el sistema almacena el evento con fecha Lunes 9 de Mayo de 2011 a las 13:00 pm UTC. Si el usuario está en Chile, se despliega la hora de la reunión restando 4 horas a la hora UTC; o en Ciudad de México la reunión se desplegará Lunes 9 de Mayo de 2011 a las 07:00 am CST (UTC-6).

Aparte de almacenar la hora UTC de un evento, otra opción válida es almacenar la hora local incluyendo la zona actual. Por ejemplo Lunes 9 de Mayo de 2011 a las 09:00 am CLT (notar CLT, que indica que la hora local está a UTC-4). Les debo la explicación de por qué esto es mejor que guardar UTC-4 o traducir a UTC.

Arbitrariedad y el Horario de verano

Esto no sería nada de grave si hubiéramos llegado hasta aquí. El problema es que la definición de zona horaria es, ha sido y será antojadiza. Chile ha tenido zonas horarias UTC-5, UTC-4 y UTC-3 (pueden leer historia de la hora oficial). Por distintas razones económicas, políticas o las que sean. Lo único seguro es que seguirán cambiando, así como habrán más segundos intercalares en el futuro y no sabemos cuándo.

Además, tenemos el concepto de horario de verano que es usado por muchos países. Cada año en Octubre se modifica la zona horaria a UTC-3 (CLST o Chile Summer Time) y se restaura en Marzo a UTC-4 (CLT o Chile Time). Esta modificación de zona también es antojadiza y es susceptible a cambios repentinos.

Todo esto es un gran dolor de cabeza para toda la gente que administra sistemas informáticos. Para comparar, cuenta en tu hogar los aparatos que manejan fecha y hora: celulares, computadores, microondas, televisores, cable satelital, etc. Y relojes, por supuesto. Imagina que debes tener todo sincronizado y lo engorroso que es, pues cada uno se configura de manera distinta. Ahora multiplica el número por 10, 100 e incluso 1000 y te darás cuenta de lo problemático que es.

Chile no es el único país que realiza estos cambios antojadizos. Son muchos los países y los cambios ocurren periódicamente. Es decir, si tienes una aplicación como un Calendario y tienes usuarios de todos los países, deberías estar pendiente de actualizar esta información periódicamente (¿Aló Google?).

Afortunadamente, hay gente que ha trabajado en una solución.

Olson y la base de datos TZ

La base de datos TZ o base de datos Olson es una iniciativa iniciada por Arthur David Olson, que consiste en código fuente y archivos con todas las modificaciones arbitrarias conocidas hasta el momento; es decir: segundos intercalares, zonas horarias, horario de verano/invierno y el historial de los cambios.

Un extracto del archivo que describe a Chile es el siguiente:

Code block

# From Glenn Eychaner (2011-03-02): [geychaner@mac.com]
# It appears that the Chilean government has decided to postpone the
# change from summer time to winter time again, by three weeks to April
# 2nd:
#
# http://www.emol.com/noticias/nacional/detalle/detallenoticias.asp?idnoticia=467651
#
#
# This is not yet reflected in the offical "cambio de hora" site, but
# probably will be soon:
#
# http://www.horaoficial.cl/cambio.htm
#

# From Arthur David Olson (2011-03-02):
# The emol.com article mentions a water shortage as the cause of the
# postponement, which may mean that it's not a permanent change.
# Rule  NAME    FROM    TO      TYPE    IN      ON      AT      SAVE    LETTER/S
Rule    Chile   1927    1932    -       Sep      1      0:00    1:00    S
Rule    Chile   1928    1932    -       Apr      1      0:00    0       -
Rule    Chile   1942    only    -       Jun      1      4:00u   0       -
Rule    Chile   1942    only    -       Aug      1      5:00u   1:00    S
Rule    Chile   1946    only    -       Jul     15      4:00u   1:00    S
Rule    Chile   1946    only    -       Sep      1      3:00u   0:00    -
Rule    Chile   1947    only    -       Apr      1      4:00u   0       -
Rule    Chile   1968    only    -       Nov      3      4:00u   1:00    S
Rule    Chile   1969    only    -       Mar     30      3:00u   0       -
Rule    Chile   1969    only    -       Nov     23      4:00u   1:00    S
Rule    Chile   1970    only    -       Mar     29      3:00u   0       -
Rule    Chile   1971    only    -       Mar     14      3:00u   0       -
Rule    Chile   1970    1972    -       Oct     Sun>=9  4:00u   1:00    S
Rule    Chile   1972    1986    -       Mar     Sun>=9  3:00u   0       -
Rule    Chile   1973    only    -       Sep     30      4:00u   1:00    S
Rule    Chile   1974    1987    -       Oct     Sun>=9  4:00u   1:00    S
Rule    Chile   1987    only    -       Apr     12      3:00u   0       -
Rule    Chile   1988    1989    -       Mar     Sun>=9  3:00u   0       -
Rule    Chile   1988    only    -       Oct     Sun>=1  4:00u   1:00    S
Rule    Chile   1989    only    -       Oct     Sun>=9  4:00u   1:00    S
Rule    Chile   1990    only    -       Mar     18      3:00u   0       -
Rule    Chile   1990    only    -       Sep     16      4:00u   1:00    S
Rule    Chile   1991    1996    -       Mar     Sun>=9  3:00u   0       -
Rule    Chile   1991    1997    -       Oct     Sun>=9  4:00u   1:00    S
Rule    Chile   1997    only    -       Mar     30      3:00u   0       -
Rule    Chile   1998    only    -       Mar     Sun>=9  3:00u   0       -
Rule    Chile   1998    only    -       Sep     27      4:00u   1:00    S
Rule    Chile   1999    only    -       Apr      4      3:00u   0       -
Rule    Chile   1999    max     -       Oct     Sun>=9  4:00u   1:00    S
Rule    Chile   2000    2007    -       Mar     Sun>=9  3:00u   0       -
# N.B.: the end of March 29 in Chile is March 30 in Universal time,
# which is used below in specifying the transition.
Rule    Chile   2008    only    -       Mar     30      3:00u   0       -
Rule    Chile   2009    only    -       Mar     Sun>=9  3:00u   0       -
Rule    Chile   2010    2011    -       Apr     Sun>=1  3:00u   0       -
Rule    Chile   2012    max     -       Mar     Sun>=9  3:00u   0       -

# IATA SSIM anomalies: (1992-02) says 1992-03-14;
# (1996-09) says 1998-03-08.  Ignore these.
# Zone  NAME            GMTOFF  RULES   FORMAT  [UNTIL]
Zone America/Santiago   -4:42:46 -      LMT     1890
                        -4:42:46 -      SMT     1910        # Santiago Mean Time
                        -5:00   -       CLT     1916 Jul  1 # Chile Time
                        -4:42:46 -      SMT     1918 Sep  1 # Santiago Mean Time
                        -4:00   -       CLT     1919 Jul  1 # Chile Time
                        -4:42:46 -      SMT     1927 Sep  1 # Santiago Mean Time
                        -5:00   Chile   CL%sT   1947 May 22 # Chile Time
                        -4:00   Chile   CL%sT
Zone Pacific/Easter     -7:17:44 -      LMT     1890
                        -7:17:28 -      EMT     1932 Sep    # Easter Mean Time
                        -7:00   Chile   EAS%sT  1982 Mar 13 21:00 # Easter I Time
                        -6:00   Chile   EAS%sT

Una de las ventajas de la base de datos Olson es que declaró las regiones o zonas de manera “sencilla” para cualquier persona. Por ejemplo, la zona correspondiente a Chile continental es “America/Santiago” y su descripción es “Most locations” y para Chile insular “Pacific/Easter” con descripción “Easter Island & Sala y Gomez“. Si has visto estas descripciones al escoger tu zona horaria, tu sistema usa la base de datos Olson.

Cabe hacer notar que todas las modificaciones a esta base de datos no es información oficial. Es solo gente común que por el bien de todos mantiene dicha información lo más veraz y actualizada posible. Basta contactarse en la lista de correos de la iniciativa, cualquiera de nosotros puede hacerlo.

Hoy muchos sistemas UNIX, bases de datos y plataformas utilizan la base de datos Olson para manejar correctamente zonas horarias, segundos intercalares y horario de verano. Sí, también las modificaciones arbitrarias a última hora.

Pero este sistema está lejos de ser perfecto, pues esta base de datos no está disponible en línea como el servicio NTP. Debe ser actualizada manualmente por cada computador, plataforma o sistema que use los archivos y muchas veces el archivo no es único sino que está varias veces en un mismo sistema.

Es por esto que una modificación al cambio de hora es un dolor de cabeza para los administradores de sistemas: Debemos actualizar: Sistema Operativo, Bases de datos (ej: MySQL), Lenguajes y Frameworks (ej: PHP y Java) y un largo etcétera.

Representaciones de fecha

Debo reiterar que es imperativo en el mundo de hoy hacer sistemas informáticos globalizados.

Lo que quiero recalcar ahora es la representación de las fechas. Lamentablemente el formato de fecha de Chile es distinto que el de EE.UU., por ejemplo. Ya saben: DD/MM/YY versus MM/DD/YY. Es algo trivial, pero genera confusión tanto a las personas como al software para expresar y leer una fecha como 02/03/04.

La solución a esto es el estándar ISO 8601, el cual define un formato del estilo YYYY-MM-DD y por supuesto incluye cosas como la zona horaria. Les ruego que lean al menos el artículo de Wikipedia, completo. Notar que el estándar también define intervalos y períodos, por ejemplo 1 vez al mes es “P1M”, algo muy útil y que mucho software sabe generar y leer (parser) actualmente.

Sé que muchos de sus clientes encuentran que la fecha “2011-03-08 19:29:34″ es horrible, incorrecta y debe mostrarse como “19:29:34 08/03/11″. Enseñen, por favor,  que en el mundo de hoy debemos pensar globalizadamente.

§

Conclusiones y los problemas no resueltos

No he terminado de levantar todos los temas, pero espero haber logrado destacar que el tema del tiempo es un problema complicado de manejar en informática.

Como norma es obligatorio utilizar algún API para trabajar con fechas y hora. Hacerlo manualmente es muy difícil y probablemente tu sistema tenga errores inesperados.

Espero hablar de los problemas actuales en un próximo artículo, pues este ya quedó demasiado extenso… Por el mismo canal y, tal vez, a la misma hora.

§

Nota 1: Es muy posible que tenga más de un error en este artículo, por favor no dude en enviarme su corrección. ¡Gracias!

Nota 2: Usualmente escribo en inglés en este blog, por hacerme el cool y enfocarme en audiencia global en vez de local. Esta es una excepción, pues me interesa que localmente se genere una discusión y ojalá se gestionen mejoras.

§

Actualizaciones 2011-03-10

• correcciones sugeridas por Alejandro Weinstein; errores menores de redacción, gramática, etc.
• correcciones sugeridas por Álvaro Herrera.