Gestión del tiempo internacional

¡Hola a tod@s!

En este artículo me gustaría destacar la importancia de utilizar el Tiempo Universal Coordinado (UTC) para el registro del horario en todos los sistemas y aplicaciones. Especialmente si está desarrollando aplicaciones con un alcance mundial.

Quienes trabajen en ENSEMBLE sabrán que cualquier registro del horario se guarda como la hora correspondiente al UTC. Otros seguramente saben que las funciones de conversión $ZDATETIME y $ZDATETIMEH tienen un parámetro de control-3 , el cual actúa de una manera muy diferente al resto, ya que transforma una cadena con formato $HOROLOG en otra cadena con formato $HOROLOG. Una es la hora local y la otra corresponde al UTC http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=...

UTC son las siglas de "Tiempo Universal Coordinado" y originalmente se le llamaba así al Tiempo Medio de Greenwich (GMT). Sin embargo, la hora en Greenwich sigue las reglas del horario de verano británico.   El UTC no considera estas reglas y le da al horario una serie de valores con crecimiento uniforme continuo.

De modo que estos cambios desde o hacia el horario de verano ya son una buena razón para alejarse del horario local cuando se realicen cálculos. En caso de que realice una copia de seguridad de sus registros, éstas pueden tardar unos 20 minutos. Si tiene la suerte de hacerlo justo en el momento en que cambia el horario en marzo, la copia de seguridad de su registro mostrará 80 minutos de duración. No muy agradable. Pero durante el cambio hacia el horario de invierno es muy raro que la copia de seguridad muestre -40 minutos.

Si únicamente se trata de un registro, esto podría ser aceptable. Si piensa en que el Administrador de tareas inicie los procesos con intervalos de tiempo específicos entre sí, esto al final causaría algún problema.

La aplicación en la que me enfrenté con este problema fue un calendario que tenía un único servidor, con usuarios distribuidos de manera global. El problema fue sincronizar las citas entre las diferentes zonas horarias y mostrar la hora que fuera más adecuada para todos los participantes en sus respectivas zonas horarias.

Como esto (en ese momento) se basó en ZEN, el método más obvio fue preguntar al navegador cuál es su zona horaria local en el momento de iniciar sesión. Los usuarios que no iniciaron sesión tuvieron su zona horaria predeterminada. No hay mucha ciencia en esto.

PERO imaginemos la siguiente situación:

Usted planea realizar una llamada telefónica con su cliente. Cuando llega el momento de la llamada que programó, casualmente ha viajado al "Global Summit" de InterSystems y se encuentra muy lejos de su casa, en una zona horaria diferente. Lo correcto sería que recibiera su recordatorio a tiempo.
Esto necesitaría una compensación temporal por el desfase horario que hay respecto a la hora que predeterminó desde su casa para la llamada.

Siguiente: El servidor de su calendario tiene una copia de seguridad oculta en una zona horaria diferente.

Ahora puede tener hasta 5 registros locales diferentes para el horario:
- hora del servidor
- hora de la copia de seguridad
- su hora local
- la hora local del lugar en donde vive
- la hora local de sus clientes.  

Mezclar las zonas horarias y las reglas del horario de verano podría convertirse en un enorme caos si utiliza cualquier otra cosa que no sea el UTC como el único registro válido para almacenar el horario.

Estoy seguro de que los profesionales que viven en países grandes y que trabajan a través de varias zonas horarias lo saben, pero sobre todo los europeos agradecen una recomendación sobre este tema. Si su empresa o la de su cliente se extiende por varios países (al utilizar con éxito los productos de InterSystems), se encontrará los problemas con el horario más rápidamente de lo que le gustaría.