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,

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.

Gracias por la info, me ha sido de muchísima utilidad.

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,

-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.

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).