UTC es un sistema de tiempo utilizado por muchos estándares en Internet y en muchos otros ámbitos. UTC es la abreviatura de Universal Time Coordinator que significa Tiempo Universal Coordinado. Es el tiempo de la zona horaria de referencia respecto a la cual se calculan todas las otras zonas del mundo.
UTC comienza a contar a medianoche (00:00) y por eso una hora UTC siempre se expresa en el formato de 24 horas (esto significa que 1:00 pm no es correcto, lo correcto sería 13:00).
Se puede completar esta información en http://es.wikipedia.org/wiki/Tiempo_universal_coordinado.
El caso es que vamos a dar soporte en una de nuestras aplicaciones a usuarios de todo el mundo y nos ha surgido la problemática de las fechas UTC.
Por ejemplo en una aplicación web, la aplicación se instala en un servidor en España, que es UTC + 1, mientras que los usuarios de nuestra aplicación estar diseminados por todo el globo terráqueo. De este modo, si un usuario en Perú (UTC -5) crea un nuevo pedido a las 15:00 (hora local peruana), y sabiendo que la hora UTC de referencia son las 20:00 (20-5 = 15), tenemos 2 opciones:
Si nuestro sistema no tiene en cuenta el tiempo UTC, el pedido se creará en base de datos con la fecha y hora española actuales, 21:00 (UTC de referencia + 1, luego 20 + 1 = 21). De este modo, si nuestro usuario pidiera un listado de pedidos no entendería que la fecha de creación del pedido sean las 21:00, cuando él sabe que debería ser las 15:00.
Si nuestro sistema si tiene en cuenta el tiempo UTC, el pedido se creará en base de datos con la fecha y hora local. Para ello, utilizaremos la fecha/hora UTC de referencia (20:00) y calcularemos la fecha y hora local. En este caso las 15:00 (fecha/hora UTC de referencia – zona horaria, 20 – 5 = 15). Lógicamente para llevar a cabo este escenario, la aplicación tiene que saber “dónde” está el usuario, es decir, la zona horaria donde el usuario opera.
Alguien podría pensar que si el usuario de Perú siempre opera en Perú, no haría falta guardar su fecha y hora local, y que se podría solucionar haciendo la operación inversa, esto es, cuando el usuario me pida un listado, como guardé la hora 21:00, le resto su UTC (-5), y le devuelvo las 15:00. Los problemas que tiene esta solución (y por lo que se descarta) son:
No siempre la conversión será tan sencilla, y muchas veces tendremos que lidiar con cambios de horario de verano-invierno, etc.
No se puede migrar fácilmente la ubicación de la base de datos a un zona horaria distinta, por ejemplo, si se cambia la aplicación y base de datos a
Puerto Rico (UTC – 4), tendríamos el problema de que todas las fechas grabadas son “españolas” y que nuestro cálculo de conversión para Perú ya no serviría, así que como parte del proceso de migración habría que actualizar todas las fechas y horas grabadas a la zona horaria de Puerto Rico.
Además, con esta solución no se permite que el usuario trabaje en distintas zonas horarias, no se permite la movilidad de los usuarios. De modo que más le vale a nuestro usuario Peruano no ir a trabajar en una zona horaria distinta (por ejemplo a Puerto Rico), porque entonces cuando pida un listado, ¿Cuántas horas restamos? ¿Las 5 de Perú o las 4 de Puerto Rico?
De ese modo, la solución válida es la segunda de las propuestas, aquella en la que grabábamos la fecha y hora local.
Algunos enlaces interesantes al respecto.
http://www.4guysfromrolla.com/articles/081507-1.aspx
http://www.codeproject.com/KB/database/ConvertUTCToLocal.aspx
Un saludo!
No hay comentarios:
Publicar un comentario