Esta es la continuación al artículo anterior “El tiempo y los sistemas informáticos“, en el que intento explicar cómo se maneja la hora local y mundial en los sistemas informáticos actuales. Recomiendo leer dicho artículo antes de continuar, pero aquí un largo resumen:
- Existe un tiempo universal llamado UTC que se basa en relojes atómicos.
- Por razones astronómicas UTC agrega/quita segundos a años arbitrarios.
- El protocolo NTP permite sincronizar la hora UTC vía Internet con una gran precisión.
- UTC sirve de referencia a la zona horaria de cada país/región. Ej: la hora estándar de Chile es CLT ó UTC-04.
- Muchos países tienen un cambio de hora o horario de verano. Ej: la hora de verano de Chile es CLST ó UTC-03.
- Por razones políticas/económicas/etc cada país ha variado el tiempo de referencia UTC antojadizamente. Este año (2011), Chile movió el cambio de hora en 3 semanas.
- La base de datos Olson contiene la información de qué zona horaria es válida para distintos rangos de fechas. Esta base de datos es continuamente actualizada por un grupo de voluntarios en una lista de correo.
- NTP no contiene información de zonas horarias ni actualiza el cambio de hora. Los cambios deben hacerse manualmente.
- En el mundo globalizado de hoy, los informáticos deben entender cómo manejar el tiempo mundialmente. Por ejemplo, es recomendable usar el formato ISO-8601
En el presente artículo intentaré explicar los problemas implicados por el (mal) manejo del tiempo. También la forma en que se resuelven y cuales aún no están resueltos. La idea es generar discusión y (ojalá) generar soluciones (que son bastante obvias) para cada problema en particular.
El error de ignorar el problema
Mucha gente cree que el problema se reduce a eliminar las modificaciones al cambio de horario invierno/verano. Que siempre sea la segunda semana de Marzo/Octubre y ya está. Creen que el tema se soluciona pidiendo a los gobiernos que dejen de ser tan desordenados y que, por favor, paren con mover el cambio de hora apenas dos semanas antes de que ocurra.
Para recalcar que los cambios de horas son inevitables, aquí un resumen del número de cambios al archivo tzdata de la base de datos Olson:
| Año | # versiones |
|---|---|
| 2011 | 4 (a la fecha) |
| 2010 | 15 |
| 2009 | 20 |
| 2008 | 9 |
| 2007 | 11 |
| 2006 | 14 |
| 2005 | 17 |
| 2004 | 4 |
| 2003 | 5 |
| 2002 | 5 |
Cada versión nueva del archivo tzdata incluye mayoritariamente una o más modificaciones a zonas horarias hechas por gobiernos de todo el mundo. Incluso, si los gobiernos dejaran de cambiar la hora antojadizamente, tenemos el problema latente de los segundos intercalares (“leap seconds“).
Pero pedir a los gobiernos de todo el mundo que dejen de modificar los cambios de hora es completamente irreal. Aún si nos escucharan, tenemos el caso latente de los segundos intercalares. Sería como pedir a la gente que deje de tener accidentes vehiculares, pues los autos no tienen cinturones de seguridad. O pedir al planeta que gire siempre con la misma velocidad. La informática debe adaptarse a la realidad, no al revés.
De la tabla, observamos que hay al menos 5 cambios por año, pero sin embargo los informáticos gritan, pelean y se preocupan con suerte una o dos veces al año. Lo que sucede es que este cambio es increíblemente complicado y costoso (veremos esto a continuación). Y cada sitio se preocupa exclusivamente de la hora local en el país en que está, por ejemplo en Chile a nadie le interesa actualizar un cambio de zona horaria en Afganistán. Es por esto que Google y muchos servicios “en la nube” están mostrando mal los calendarios que quedaron agendados estas semanas en Chile: es muy complicado/es muy caro/que lo resuelvan los usuarios. En resumen, a nadie le importa.
Por qué es tan costoso modificar el cambio de hora invierno/verano
Primero, por un tema de volumen. La cantidad de aparatos y sistemas informáticos no paran de crecer. Cada vez se hacen más invisibles, pero estamos rodeados de sistemas y aparatos: un scanner médico, tu celular, el cajero automático, el reloj del control horario, y un largo etc..
Segundo, por un tema de diversidad: la hora es entregada por el sistema operativo y no todos los aparatos usan el mismo sistema operativo. Luego, el procedimiento es distinto para cada tipo de aparato o sistema informático. Peor aún, la gran mayoría de los sistemas no tiene incorporado la funcionalidad para realizar una modificación al cambio de hora. Es un problema aún no resuelto en el mundo de la informática. Es decir, aparte de realizar la modificación, tendremos que analizar los datos del sistema para que ahora estén correctos con el nuevo horario.
Esto significa que cada modificación al cambio de hora se transforma en un mega proyecto informático que involucra a todos los computadores de cada instalación y a todos los sistemas informáticos. Y los gobiernos anuncian la hora con apenas un par de semanas antes de la fecha en que ocurre el cambio de hora automático. Un par de semanas antes de que ocurra el cambio es insuficiente para un cambio de esta envergadura. Ninguna empresa está preparada para tremendo proyecto en un par de semanas.
Lo que sucede en la práctica es que la gran mayoría de sistemas falla y presenta una hora incorrecta o información incorrecta.
Además, la precisión o calidad con que los sistemas manejan la hora local/mundial varía bastante. Por ejemplo, el soporte a UTC de los sistemas operativos Microsoft es bastante deficiente: modifican la hora del PC en vez de tener el reloj en UTC y cambiar la representación (esto es fatal para que NTP calcule correctamente la desviación respecto a los relojes atómicos) y no tienen soporte a segundos intercalares. Es probablemente por esto que nunca verás un sistema Windows manejando aparatos que requieren exactitud en este tema, como aparatos astronómicos, de navegación, etc.
Debido a que muchos sistemas operativos lo hacen de manera deficiente, hay mucho software que no usa lo que trae el sistema operativo e incluyen el código de Olson. La máquina virtual de java, servidores MySQL, PHP y un largo etcétera tienen su propio sistema con su propio archivo basado en tzdata. Es decir, para realizar el cambio debemos asegurarnos cada una de las siguientes capas:
- En el sistema operativo
- En cada uno de los subsistemas y plataformas: bases de datos, plataformas de desarrollo, API’s y middleware
- En las aplicaciones
- En los datos que tienen las aplicaciones
Actualmente, los sistemas UNIX resuelven sólo la primera capa, el sistema operativo: las actualizaciones al archivo tzdata se pueden automatizar sin mucha dificultad. Esta modificación sigue siendo bastante costosa (y muchas veces es simplemente imposible), pero la automatización facilita bastante. Pero las capas 2, 3 y 4 no están contempladas por nadie actualmente. La mayoría de las veces simplemente se ignoran.
Finamente, un par de semanas es insuficiente para que cada proveedor genere un parche a los sistemas. En UNIX usualmente este parche está disponible entre 1 o 2 semanas después de anunciado el cambio de manera oficial, lo que en la práctica implica que el mismo día del cambio se están parchando todos los servidores. Los parches de Microsoft se demoran 1 o 2 meses en salir, en la práctica no hay parche oficial y se debe realizar modificaciones al sistema de manera manual. Apple demora 3 a 4 meses en liberar un parche, tu iPhone se quedará con la hora incorrecta simplemente.
Las soluciones “obvias”
- Exigir a los gobiernos que los cambios de hora deben ser anunciados con al menos 8 semanas de anticipación. Esto permite que los proveedores generen un parche a tiempo. Esto no quita el costo, sino que nos permite alcanzar los aparatos y sistemas que simplemente se ignoran cuando un cambio es repentino. Recuerden que esto toca a todos los aparatos y sistemas informáticos.
Nota de borrador
Este artículo está en borrador y he decidido lanzarla antes, debido a la urgencia que tenemos hoy en que el Gobierno de Chile intenta mover el cambio de hora a solo 5 días de que este ocurra.
Invito a las autoridades que me inviten a su despacho, yo personalmente les puedo explicar con detalles la gravedad del problema.
No sé cómo serán las aplicaciones de las que hablas, pero las que yo conozco delegan el trabajo de calcular y manipular fechas y horas a la base de datos: toda la gestión de fechas es parte de la BD, no de la aplicación. Si a esto le sumamos que PostgreSQL es capaz que utilizar los archivos Olson del sistema operativo en lugar de los propios, resulta que lo único que es necesario actualizar son los archivos de Olson del sistema operativo, nada más.
Álvaro, estás viendo el tema con muy corta vista.
Mira los celulares, los relojes, los netbooks, las aplicaciones en la nube y un gran etcétera. Estamos rodeados por sistemas que NO usan bases de datos. Por supuesto, la gran mayoría NO USA PostgreSQL.
Por si mismo, el actualizar el tzdata es una gran joda. Tenemos que tocar TODOS los computadores. Eso es gigante. Peor aún, a veces tenemos que tocar los subsitemas: mira PostgreSQL para Windows, que trae su propio archivo tzdata.
Además, no basta con actualizar los archivos Olson. Eso soluciona la primera de mis 4 capas, el sistema operativo; pero no la última, los datos de la aplicación. El ejemplo clásico: si ya agendaste un evento para el Lunes 4 de Abril a las 09:00 hrs con el TZDATA antiguo, tendrás que modificarlo. Y eso depende de cada aplicación, no es una decisión que pueda tomar el sistema operativo.
“El ejemplo clásico: si ya agendaste un evento para el Lunes 4 de Abril a las 09:00 hrs con el TZDATA antiguo, tendrás que modificarlo.”
En este caso, las aplicaciones estan mal, tienen que trabajar solamente con tiempo UTC internamente, para luego ser mostrados al cliente en su zona horaria.
Con respecto al post en general, efectivamente esta cuestion del cambio de hora constante es un PITA.
No Cristian, cometes el mismo error que la gran mayoría. Guardar la hora en UTC no te quita corregir los problemas en la capa 4 (datos de las aplicaciones).
El ejemplo completo:
A) Hoy 2010-03-28 agendas en el calendario una cita para el Lunes 4 de Abril 2010 a las 9:00 hrs America/Santiago. El sistema almacena internamente en UTC la hora 2010-04-04 13:00 hrs UTC. Notar que el sistema asume que el 4 de abril la zona horaria para America/Santiago es UTC-4.
B) Sale el decreto que deja UTC-3 hasta Mayo. Se parchan los sistemas antes del día Sábado sin modificar los datos.
C) Notar que después del parche, la cita aparecerá incorrecta: 2010-04-04 13:00 hrs UTC será ahora 2010-04-04 10:00 hrs CLST.
Espero se entienda. Tal vez digas: entonces no guardemos la hora UTC, pero esto trae otros problemas… el tema no es tan trivial como la mayoría de los informáticos piensa.
Esperaba completar bien este artículo, pero por ahora me interesa levantar la alarma.
Si almacenas todo en UTC, te encontrarás con un problema cuando las definiciones de las TZ cambien. En algunos casos es mejor almacenar fechas usando la zona local.
Estoy de acuerdo con la idea de que todo esto es un desastre, y que hay miles de problemas que traen un gran costo tanto para los admins como para los usuarios.
Lo único que estoy argumentando es que “los datos de la aplicación” deberían estar en una base de datos, y si hay cambios en los datos, los puedes implementar en la base de datos sin tocar la aplicación.
(Respecto de tzdata en PostgreSQL en Windows: en realidad Postgres trae tzdata en todas las plataformas. Sólo que algunas versiones empaquetadas para algunas plataformas (por ej. Redhat y Debian) aprovechan el tzdata del sistema operativo en lugar de usar el propio, lo cual es conveniente para situaciones como esta. No ayuda a las otras plataformas, claro).
Son muy validos los puntos de vistas, pero creo que el tema debería ser jerárquico en cada sistema en el orden de dependencia:
-Aplicaciones del usuario dependen de:
-Base de Datos y datos del usuario, que dependen de los:
-Subsistemas y/o middleware, que a su vez dependen del:
-Sistema Operativo
Es decir, que las aplicaciones del usuario dependen al final del sistema operativo en configuraciones de zona horaria. el parche del sistema operativo podría corregir el problema hasta el nivel de aplicación, haciendo transparente la actualización hacia las capas superiores.
esperando sus comentarios
Saludos
Alex.
Alex, tu razonamiento me suena correcto y es bastante obvio después de analizar el tema. Pero creo que te faltan algunos puntos importantes en tu análisis. Te adelanto un poco lo que tenía en borrador del artículo para que entiendas por qué tenía las aplicaciones antes que los datos.
En ningún caso este problema está resuelto por nadie, a nivel mundial. Separemos los datos en dos: 1) información ingresada posterior a la modificación; y 2) información ingresada antes de la modificación.
La información nueva 1) es lo más fácil de solucionar. DEBIERA bastar con lo que dices: actualicemos el TZDATA en el sistema operativo y ya está. Pero hoy no es así: a veces el sistema operativo tiene un deficiente soporte a zonas horarias y/o UTC. Por eso cada subsistema trae una copia del TZDATA y debes parchar cada subsistema. Además, el cambio no es inmediato: debemos reiniciar las aplicaciones.
Si este problema estuviera resuelto, podría existir una suerte de servicio en internet como NTP que sincronice las zonas horarias. Esto haría trivial el cambio de hora, pero hoy no es posible. Se debe mejorar los S.O y modificar/mejorar las aplicaciones para que tomen el cambio inmediatamente. No está resuelto.
La información vieja 2) es lo más complicado, pues requiere modificar los datos. Veo 3 casos:
A) Datos que deben manejarse en la zona horaria local. Por ejemplo, vencimientos o agendamiento de eventos locales.
B) Datos que deben manejarse respecto a UTC o un tiempo “sin saltos” para poder calcular deltas. Por ejemplo, un evento recurrente cada 25 minutos.
C) Datos que deben soportar ambos esquemas: mostrarse en la zona horaria local Y mostrarse respecto a un tiempo universal. Por ejemplo, el calendario de exchange/google para eventos internacionales.
En el caso A) basta con no modificar los datos y usar una buena definición en la programación. Por ejemplo, guardar los datos sin información de zona horaria. Muchos sistemas asumen esto, como los que tienen campos de día/mes/año en la base de datos en vez de usar un timestamp. Pero la gran mayoría necesita comportarse como el caso C). Por ejemplo para decirte “en 1 hora más tienes reunión”, el cambio de zona puede descuadrar la información vieja. Cuando alguien programa: en 30*24*60*60 minutos es el mes siguiente, es típico que cae en errores por asumir que el sistema se comporta como A) cuando debiese comportarse como C).
El caso B) es relativamente sencillo si lo conoces. Mucho del software basado en UNIX se comporta como B): se usa un timestamp que cuenta milisegundos desde una fecha en particular o “epoch”. En este caso lo que se debe hacer es NO modificar los datos. Basta tener actualizado TZDATA de manera de poder mostrar la información nueva. El problema es que mantener el TZDATA actualizado no está resuelto (ver información nueva 1). El otro problema es que, dado que es lo que usa por omisión el sistemas, muchos informáticos programan utilizando este tipo de timestamp cuando necesitan uno del caso A) o del caso C).
El caso C) es, en mi opinión, lo que la gran mayoría de las aplicaciones necesita. Para resolverlo, necesitas que tu aplicación SEPA como corregir los datos cuando hay una modificación al cambio de hora. Debido a que cada aplicación es la única que conoce si una fecha es de tipo A), B) ó C); es la aplicación la que tiene el control de qué datos modificar, no el sistema operativo ni los subsistemas.
Para hacerlo como tú mismo indicas, que baste cambiar el sistema operativo y todo se cambia hacia arriba, también necesitamos otra cosa: que el sistema operativo entregue la información de qué CAMBIOS se hicieron, de manera que la aplicación pueda automáticamente aplicar los cambios. Esto tampoco está resuelto en TZDATA ni en ningún sistema, de hecho es una de mis propuestas que estaba analizando y por eso no había publicado este artículo hasta tener listo ese código.
Finalmente, en el caso C) necesitas guardar más información: a qué zona horaria corresponde un timestamp. Así podrás distinguir a qué datos hay que aplicar la modificación (por ejemplo, si tienes datos de America/Santiago y Africa/Casablanca, sólo debes modificar los primeros).
Como ves, este tema es mucho mas complicado de lo que parece. Saludos,
Es impresionante como tantos buenos computines todavía no entienden el problema de fondo. Como dice Aldrin: el problema no es actualiza la zona horaria del sistema operativa; el problema está en los datos antiguos que se crearon pensando que las reglas del juego eran de cierta manera. En fin…
Excelente resumen Mañungo, muchas gracias.
Pta, llegué aquí pq tenía una lijera duda de comportamiento de tanto cambio de hora, que se corre primero un mes, que se corre de nuevo avisando con apenas 1 semana de anticipación y ya estaba vuelto loco con mi aplicación (trabajo con calendarios, cron y mailing automático donde en los 3 procesos es importantísimo la hora) y me di cuenta que el tema es por lejos muchísimo más complicado que simplemente cambiar la hora de forma manual y listo.
Gracias por la info, me ha sido de muchísima utilidad.
Aldrin, buen articulo, si bien planteas el tema de la forma amplia, olvidas un aspectos que los computines, y sobre los open source no aplican, que es la planificacion, si bien somos mas ‘agiles’ y eficaces en las soluciones, no tenemos la capacidad de salir de nuestra isla y solucionar todo el entorno, Solo el accionar coordinado y planificado permite que estos cambios esten libres de fallas.
De lo mismo imagina los sistemas que tarificacion, los cuales no son tan evidentes,
Como nota ej. hace dos noches puse un ticket en Dell.com y ellos tenian la zona ‘antigua’ de chile y por lo tanto ya no me atendieron por q estaba fuera de horario de soporte.
Eduardo: abarcar el tema por completo es difícil en un solo artículo.
Entiendo tu postura que va por el lado “operativo”, en el que más que mejorar el mundo tienes que sobrevivir con lo que hay, pero en el artículo original me interesaba buscar solución a algo que claramente no está resuelto.
Lo interesante es, como dijo @abarros en @eltestacido, el tiempo es una variable que afecta TODOS los sistemas. Y esto es algo que muy poca gente se ha dado cuenta.
Slds,