Spanish [Solucionado] B4J: Diferencia del reloj sin el horario de verano. (México)

[Fernando Solá]

Ahora que se eliminó el horario de verano en México, en aplicaciones desarrolladas con B4J me encuentro con que al consultar la hora con DateTime.Time(DateTime.Now) en Windows 10, aparece como si estuviera vigente el horario de verano y la hora reportada tiene una diferencia de una hora más. Para fines de ciertos registros es importante tener la hora correcta.

¿Alguien ha notado ese comportamiento? ¿Cómo lo han resuelto?

Por ahora, la forma que he encontrado para solucionarlo es colocar un parámetro en mis aplicaciones para habilitar y deshabilitar manualmente el horario de verano y ajustar el timezone a -6. La realidad es que no sabemos si en un futuro puedan volver a implementar el horario de verano o no y tener que hacer correcciones en las bases de datos después de eso, no es algo que alegremente quiera volver a hacer.

Anexo un ejemplo de B4J para pruebas y para que me comenten al respecto de si pueden replicar la situación.

Me gustaría conocer si han notado esto y como es que lo están resolviendo.

¡Saludos!

 

[drgottjr]

funciones relacionadas con la fecha, la hora, etc
dependen del sistema operativo que controla la
computadora en que se ejecutan. no dependen
de b4j. en cuanto a windows, microsoft lo actualiza
de acuerdo con sus practicas (que estan publicadas
aqui: https://learn.microsoft.com/en-us/t...-components/daylight-saving-time-help-support)

para usuarios de tus apps que no tienen la version mas reciente de windows,
es posible - quiza probable - que tendras que implementar alguna prueba antes
de dar por hecho que el asunto se arregla de por si solo. hay servicios online que
publican la hora del dia para cualquier lugar del mundo. podrias consultar uno de
ellos, ej, al abrir la app.

 

[Fernando Solá]

funciones relacionadas con la fecha, la hora, etc
dependen del sistema operativo que controla la
computadora en que se ejecutan. no dependen
de b4j. en cuanto a windows, microsoft lo actualiza
de acuerdo con sus practicas (que estan publicadas
aqui: https://learn.microsoft.com/en-us/t...-components/daylight-saving-time-help-support)

para usuarios de tus apps que no tienen la version mas reciente de windows,
es posible - quiza probable - que tendras que implementar alguna prueba antes
de dar por hecho que el asunto se arregla de por si solo. hay servicios online que
publican la hora del dia para cualquier lugar del mundo. podrias consultar uno de
ellos, ej, al abrir la app.

Agradezco la información que me has compartido.

Totalmente de acuerdo que dependen del sistema operativo, que en este caso resultó ser Windows 10 (22H2) con todas las actualizaciones aplicadas al día de hoy. Hasta ahora no he tenido la oportunidad de probarlo en Windows 11 para ver si existe alguna diferencia con respecto a como maneja el asunto del ahora inexistente horario de verano en México. Cuando tenga acceso a equipos con Windows 11 podré probarlo, pero por ahora la información que la comunidad pueda aportarme, especialmente en México es bien recibida y agradecida. Por ello es que pido información sobre si han notado situaciones similares o no y que en cualquier caso pueden observarlo con el programa de ejemplo adjunto que imprime en el Log tanto la zona horaria como la hora que B4J reporta.

Explicando más claramente la situación: Al consultar DateTime.TimeZoneOffset me muestra que el TZ es -5 en lugar de -6. Windows está configurado en UTC-6 Guadalajara, Mexico City, Monterrey. Esa diferencia empata bien con la diferencia de una hora que muestra el programa contra la hora que reporta el reloj del sistema operativo. Obviamente esto causa diferencias en aplicaciones en las cuales la hora es importante; por ejemplo: Un programa que registra la hora de entrada y salida de un empleado. Windows dice que son las 8:50 am su entrada y el programa reporta que son las 9:50 am. Lo mismo con la salida y todo ello tiene consecuencias y costos: El usuario acumula retardos y sanciones y/o la empresa paga horas extras que no se laboraron.

Me queda claro que no es un problema con B4J, sino con la forma en la que la actualización de horarios de Windows fue hecha para esta versión. Ciertamente se tiene que resolver dentro del programa y es absolutamente imprescindible tener ese parámetro de configuración bajo las condiciones actuales para que la hora que reporta el programa sea exactamente la misma hora que informa el reloj del sistema operativo. Todo eso lo trato de ilustrar de la forma más sencilla posible en el programa ejemplo que adjunté en el mensaje original.

De cualquier forma creo que es importante dejar una evidencia y referencia a esta situación por si algún otro programador se encuentra con una situación similar. Tal vez en un futuro alguien más decida volver a implementar el horario de verano, tal vez no, pero por ahora existe y es real la discrepancia que menciono. Anexo imagen para ilustrar la diferencia en el TZ Configuración de Windows vs DateTime.TimeZoneOffset en B4J

Saludos.

 

[Fernando Solá]

Pues después de muchas horas de investigar, resulta ser que el problema no es por Windows sino por la versión de Java. Los TZ y los respectivos cambios de horarios están en una base de datos contenida en el JVM Y para ajustarlo existe una herramienta provista por Oracle:

https://www.oracle.com/java/technologies/downloads/tools/#TZUpdater

Esto implica que hay que actualizarlo en todos los equipos que corren las aplicaciones con un JRE que no tiene los horarios de verano actualizados.

Se puede dar la vuelta a través de código de B4J, también usando varios elementos. jShell (en Windows con la instrucción: powershell Get-TimeZone | find "BaseUtcOffset"), JavaObject (la clase java.util.TimeZone y los paquetes java.time y java.time.zone ofrecen herramientas útiles) y DateTime.TimeZoneOffset y DateTime.SetTimeZone permiten hacer esos ajustes por código.

En el caso de México encontré que hasta la versión 20 del JDK y OpenJDK se incluyen los cambios de la anulación del horario de verano, sin embargo no es la opción más amigable para trabajar con B4J y probablemente cause más dolores de cabeza hacer el cambio solo para hacer ese ajuste.

Espero que esta información le sea útil a alguien quien se encuentre con una situación similar en el futuro.

 

[EnriqueGonzalez]

En el caso de México encontré que hasta la versión 20 del JDK y OpenJDK

probablemente las versiones anteriores tambien lo tengan en actualizaciones de mantenimiento.

Oracle JDK

Check end-of-life, release policy and support schedule for Oracle JDK.

endoflife.date

Almenos la version 11 y 17, en teoria B4J funciona con JDK 14 aunque no lo recomendaria, al igual que con JDK 20 ya que no son versiones LTS.

En todo caso si usas el JDK oficial del foro, es probable que si tengas que correr la herramienta que nos pasaste.

gracias!

 

[Fernando Solá]

probablemente las versiones anteriores tambien lo tengan en actualizaciones de mantenimiento.

Almenos la version 11 y 17, en teoria B4J funciona con JDK 14 aunque no lo recomendaria, al igual que con JDK 20 ya que no son versiones LTS.

En todo caso si usas el JDK oficial del foro, es probable que si tengas que correr la herramienta que nos pasaste.

gracias!

Si, es correcto. Creo que el punto importante es saber por qué se da la situación y que existen formas para remediarlo. Al final, no sabemos si en un futuro a alguien se le ocurrirá volver a habilitar el horario de verano y con ello de nuevo tener que hacer cambios con el TZUpdater o en el código o cambiando parámetros que como programadores podemos implementar.

Por ahora tanto las correcciones a la base de datos como la corrección urgente para forzar el TimeZone a -6 y su distribución en los equipos ya está hecho. Todavía queda mucho por hacer después de que estalló esta situación. Ahora me dedicaré a probar que puedo hacer con la herramienta para distribuir los cambios del el TZUpdater de la forma más eficiente posible. Me parece que hay un par de archivos (tzdb.dat y tzmappings) que son los que se deben afectar, pero por eso necesitaré hacer pruebas antes de poder emitir la solución más efectiva. Va a ser un fin de semana interesante.

Muchas gracias por tus comentarios.

¡Saludos!