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

#1 by Silvio on enero 7, 2008 - 10:19 am
Citar
Muy bueno este reporte, pero quiero comentarles que en relacion al cambio de hora (aqui en Argentina) estoy con un problema con websphere 5.1 , segui las instrucciones de IBM instalando JTZU Version 1.6.7k para solucionar este tema y no tuve éxito.Alguna sugerencia ?????
Gracias
Silvio
#2 by Igvir on enero 7, 2008 - 10:28 am
Citar
Silvio:
Hace falta conocer mas detalles de lo que no esta funcionando en tu caso para poder darte alguna sugerencia.
#3 by Silvio on enero 7, 2008 - 11:05 am
Citar
Puntualmente el problema esta en que las JVM que corren sobre los applicationes servers no se actualizaron con los cambios que se realizaron el 30/12/2007 en todo el pais(por decreto del gobierno Argentino).
El gobierno Argentino decreto realizar un “adelanto de 1 hora ” a partir de la 0:00hs del 30 de dieciembre pasado.
Segun IBM, la recomendacion que da es correr esta aplicación JTZU Version 1.6.7k para actualizar la tabla de calcuro horario de la JVM y por ultimo realizar un reinicio del servidor pero no funciono.
El timezone correcto que deberia tomar la JVM es GMT-03:00 Buenos Aires pero no lo hace.
Gracias por respuesta!
Silvio
#4 by Igvir on enero 7, 2008 - 11:44 am
Citar
Ok Silvio vamos mejorando:
No lo dices en tu respuesta pero si no funciona asumo que estas trabajando WAS en Windows. Ahora bien, lo que en este caso nos funciono fue aplicar el parche del cambio de horario de Microsoft y luego hacer el cambio en el registro de Windows y en el archivo tzmappings de WAS.
Verifique en mi maquina virtual y mi archivo tzmappings tiene estas entradas para Argentina:
SA Eastern:42,43::America/Buenos_Aires:
SA Eastern Standard Time:42,43::America/Buenos_Aires:
El parche de Microsoft debe haber creado un nuevo TZ para Argentina, lo que hacemos es de enlazar ambos cambios. Mi recomendación, usa los mismos valores (ej:42,43) para la entrada que agregues en tu caso.
#5 by Silvio on enero 7, 2008 - 12:27 pm
Citar
Igvir,efectivamente este was corre sobre windows.
Mi archivo tsmappingz es similar al tuyo
SA Eastern:42,43::America/Buenos_Aires:
SA Eastern Standard Time:42,43::America/Buenos_Aires:
Respecto al parche de Microsoft, la semana pasada nos enviaron un procedimiento para realizar el cambio de hora en el sistema operativo pero en la consola del was sigue con la hora vieja.
tengo entendido que hay una forma de iniciar la JVM y darle una serie de parametro con la llamada “user.timezone” al iniciar la JVM¿tienes idea si esto funciona?
Gracias
#6 by Igvir on enero 7, 2008 - 5:46 pm
Citar
Pasar por parametro la variable user.timezone funciona para las aplicaciones pero según pudimos ver no tiene efecto sobre los mensajes de la consola de WAS generados por el propio WAS. Como dije tus aplicaciones si veran bien sus propios logs.
Las zonas horarias estan en el registro de windows bajo
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones
En el caso de Venezuela Microsoft añadió un nuevo TimeZone para Caracas con el cambio de Horario. Habría que verificar que fue lo que hicieron en el caso de Argentina. Si agregaron uno nuevo, como te digo lo que tienes que hacer en vincular el nuevo TimeZone con el que conoce la JVM, es decir, America/Buenos_Aires
Si en lugar de crear uno le asignaron alguno ya existente, solo tienes que buscar en tu archivo de mappings y asociarle este que ya existia a America/Buenos_Aires
#7 by Silvio on enero 8, 2008 - 10:55 am
Citar
Igvir, Gracias por tu sugerencia!!!! me han servido para solucionar este tema.
Aun estoy esperando que el soporte de IBM me den alguna recomendación..sin palabras..
Desde ya mil gracias!!
Atte
Silvio
#8 by Gabriel Lobo on enero 11, 2008 - 12:38 pm
Citar
Posterior a aplicar el patch de windows y el de sun… asi como realizar el cambio que comentas en el tzmappings me encuentro con lo siguiente:
Si coloco en la maquina el timezon La paz en efecto al obtener la fecha me la trae bien…
Timezone: America/La_Paz
Numero de milisegundos a agregar de tiempo UTC: -14400000
Fecha retornada por sistema: Fri Jan 11 12:32:31 BOT 2008
Hora GMT: 11 Jan 2008 16:32:31 GMT
Cuando hago el cambio de uso horario en el reloj de la maquina para Caracas me vuelve a gmt..
Timezone: GMT
Numero de milisegundos a agregar de tiempo UTC: 0
Fecha retornada por sistema: Fri Jan 11 16:32:15 GMT 2008
Hora GMT: 11 Jan 2008 16:32:15 GMT
Cambie tzmappings:
SA Western:-1,82::America/La_Paz:
SA Western Standard Time:-1,82::America/La_Paz:
Venezuela Standard Time:90,90::America/Caracas:
debo modificar algo en el registry?
#9 by Igvir on enero 11, 2008 - 3:21 pm
Citar
Gabriel, lo mas sencillo es que cambies tu tzmappings usando el -1,82 para caracas.
es decir, cambia la linea del Venezuela Standard Time por esta:
SA Western:-1,82::America/Caracas:
Eso debería ser sufuciente