El pasado 09 de Diciembre 2007 nos toco retroceder 30 minutos nuestro reloj. A partir de ese cambio se desprenden distintas implicaciones, entre ellas lo que a mi trabajo se refiere: Los sistemas de computación. Antes de continuar les comento que este será un artículo con algunos detalles y especificaciones técnicas.
Como ya explicaba Robert en La Cara Oscura. Distintas empresas ofrecieron soluciones de diferentes maneras, IBM, SUN y Microsoft dieron a conocer sus soluciones en distintos momentos pero todos aseguraban esta listos. Hasta aquí no hay nada nuevo. Sin embargo, dos días después de la implantación completa de las correcciones nos dimos cuenta que cuando tienes tres empresas trabajando separadas en la solución de un mismo problema, es probable que sus soluciones no se entenderán entre ellas.
Si tienes Windows y sistemas desarrollados en Java este es un punto que te debe interesar. Lo primero que debes hacer es entender la solución de cada empresa. Para Microsoft, la solución fue separar la Zona Horaria conocida anteriormente como “Caracas/La Paz” por una Zona Horaria independiente para Venezuela nombrada “Caracas (-4:30) y definida en el registro de Windows como “Venezuela Standard Time”. En resumen, Caracas y La Paz ya no andan juntas (triste realidad).
Para SUN e IBM, y sus respectivas maquinas virtuales, el cambio se limito a actualizar la base de datos de Zonas Horarias. En el artículo de Robert, hay mas detalles de esta implementación. El problema viene luego de actualizar la maquina virtual de Java y el sistema operativo Windows.
Luego de analizar el comportamiento de la aplicación al imprimir la fecha del sistema notamos que algo andaba mal. Contactamos a Robert y empezamos a trabajar en alguna solución. Microsoft, SUN e IBM no se estaban entendiendo. El servidor de aplicaciones Websphere y la JVM imprimian horas en formatos distintos al esperado por los clientes. Robert verifico los datos y noto que estaban correctos el problema era al presentarlos, un tema de “formato”. Luego verificamos la Zona Horaria por defecto, allí encontramos la primera pista, en lugar de ser “America/Caracas” el valor por defecto era “GMT” para version 1.5 o inferior y “America/Rio_Branco” para la 1.6 con el Fix de Robert. Al mirar mas a fondo notamos que la solución de Microsoft omitió el valor MapID que tienen (o tenían) las Zonas Horarias incluidas en el registro de Windows. Este valor es clave para Java ya que sirve de enlace entre las Zonas Horarias de Windows y las de la maquina virtual.
¿Que significa esto? Básicamente que tus aplicaciones Java tendrán una Zona Horaria distinta a Caracas como valor por defecto. La razón es que con los parches se “rompio” el enlace entre ambas bases de datos de zonas horarias. La forma mas fácil de solucionarlo es usar el parametro de la maquina virtual e indicarle la zona horaria, algo como java -duser.timezone=America/Caracas pero esto tendríamos que hacerlo para cada aplicación afectada.
¿Como solucionar este enlace roto para todas las aplicaciones que usan la JVM?, cambiando el archivo tzmappings para “enlazar” ambas bases de datos. El problema es que el registro de Windows, al no contar con un ID “oficial”, nos obliga a seleccionar uno “nuestro” que permita reordenar ese lio. Es así como llegamos al valor 90/90. Por ser superior al ultimo valor del archivo de tzmappings en la versión 1.5 y no interferir con ningún valor de la versión 1.6 de la maquina virtual. Con el cambio, el archivo ahora contiene una entrada así:
Venezuela Standard Time:90,90::America/Caracas:
Esto le dice a la maquina virtual que enlace el “Venezuela Standard Time” con el America/Caracas. como ven se indica el MapID=90/90. esto quiere decir que en maquinas previas a la versión 1.6 debe existir un MapID en el registro igual a 90/90. Si estas utilizando la maquina virtual 1.5 y no puedes cambiar a la versión más reciente, la solución es modificar el registro de Windows.
Por suerte, la versión 1.6 de la JVM de SUN parece estar “preparada” para la omisión del MapID de Windows y reconoce la zona horaria buscándola por el nombre. Así que si para aquellos que trabajen con la versión 1.6 no hará falta la modificación de registro de Windows.
Luego de estos cambios las aplicaciones comenzaron a entender que seguían en la zona horaria de caracas. Es así como con un par de cambios, esta noche podremos dormir en casa, en Caracas y en paz (que no en La Paz).