Aprende a manejar fechas en proyectos internacionales
Mapa de zonas horarias del mundo. Créditos: Wikipedia.
Artículo originalmente publicado en Secture&Code
Las fechas son una de las grandes olvidadas en los planteamientos iniciales de un proyecto y esto puede tener repercusión en el mantenimiento a medio largo/plazo. Inicialmente, cuando arrancamos un proyecto simplemente guardamos la fecha y la hora sin preocuparnos demasiado al respecto, pero luego proyecto crece, requiere una adaptación para el mercado internacional (internacionalización) y centramos todo el foco en las traducción y la localización de nuestro sitio web.
Pero, ¿acaso es la misma hora en todos los países? ¿Acaso en España no cambiamos la hora dos veces al año?
Aunque parezca poco importante, puede provocar auténticos desastres administrativos a nuestro proyecto, como, por ejemplo, publicar un producto en otro país 6h antes de lo esperado, o que tareas programadas se ejecuten una hora antes o después de lo necesario debido al cambio de hora.
¿Cómo manejamos todo esto?
Zonas Horarias
En realidad el sistema horario internacional es algo que todos conocemos y que todos los lenguajes de programación de alto nivel que implementan fechas tienen incorporado a su API, por lo que abordar este problema solo requiere de un poco de planificación, consenso y disciplina.
Cuando generamos una fecha con nuestro lenguaje preferido, este, generalmente, lo hará utilizando la zona horaria configurada. Esta configuración puede tener distintos orígenes y prioridades. Veamos algunos ejemplos ordenados de más prioritarios a menos prioritarios:
- Configuración en runtime (en tiempo de ejecución): acabamos de configurar el lenguaje para que use una zona por defecto
- Configuración del framework o librería de fechas : a lgunos frameworks te permiten ajustar este parámetro para que en todo el proyecto se use la misma configuración (a no ser que se sobreescriba en runtime).
- Archivos de configuración : los lenguajes interpretados suelen dejarnos ajustar algunos parámetros del intérprete en archivos del sistema.
- Configuración del sistema operativo : s i ninguna de las anteriores ha sido configurada, por defecto usará la del sistema.
⚠ ️ Pro Tip: atención con la configuración de la zona horaria de la base de datos, ya que si permitimos que el motor de la base de datos asigne fechas automáticamente, este lo hará siguiendo su propia configuración, que no tiene por qué ser la misma que la del lenguaje o _runtime._
Coordinated Universal Time (UTC)
Hay una zona horaria especial que nos permite controlar a la perfección estas diferencias entre las distintas zonas horarias, y es la zona UTC (Coordinated Universal Time). Esta zona es la “zona cero”, es decir, no tiene desplazamiento horario, podríamos llamarlo la hora central del planeta. En otros contextos se le conoce como GMT (Greenwich Median Time), aunque UTC es el reemplazo oficial de GMT. En argot militar también se le conoce como Hora Zulú, y permite coordinar operaciones usando una hora común.
Si guardamos todas nuestras fechas en zona UTC, podremos calcular muy sencillamente la fecha en cualquier zona del mundo. De hecho, ni siquiera tendremos que hacer los cálculos, ya que es una función muy común en cualquier librería de fechas o incluso en las APIs propias de los lenguajes de programación. Veamos un ejemplo en PHP:
En este caso he optado por configurar la zona por defecto en runtime, solo para ejemplificar su uso.
Lo interesante de este uso es que el frontend puede determinar la zona horaria del usuario por distintos métodos (dominio, IP, selección manual del usuario…) y mostrar las fechas que vienen del backend ajustadas a la zona horaria del usuario, sin errores, sin problemas derivados por el horario de verano… etc. Y, simultáneamente, el tiempo de todas nuestras operaciones queda coordinado por una hora única en el backend.
Formatos de fecha
El cómo queramos mostrar la fecha a los usuarios ya es un asunto más personal o cultural, en base a los diferente países a los que vayamos a mostrar las fechas. Vamos a ver algunos de los ejemplos más recurrentes:
Formato francés
Es el más extendido en Europa, consiste en una ordenación de día, mes y año, en ese orden. Por ejemplo:
- 13/12/1989
- 13-12-1989
Da igual el uso de barras, guiones… lo importante es el orden. En caso de mostrar la hora, esta se muestra a continuación separada por un espacio en blanco, con la ordenación hora, minutos, segundos:
- 13/12/1989 11:24:26
Formato americano
Es el más extendido en America. Consiste en una ordenación de mes, día y año, en ese orden. Por ejemplo:
- 12/13/1989
- 12–13–1989
Da igual el uso de barras, guiones… lo importante es el orden. En caso de mostrar la hora, esta se muestra a continuación separada por un espacio en blanco, con la ordenación hora, minutos, segundos:
- 13/12/1989 11:24:26
Estándar ISO-8601
Se sigue el criterio de especificar en orden primeramente los períodos de tiempo más largos y posteriormente los más cortos. Así, para especificar una fecha primero se escribe el año, posteriormente el mes y a continuación el día.
Por ejemplo, para especificar la fecha 13 de diciembre de 1989 del ejemplo anterior, el resultado sería:
- 1989–12–13
En el caso de incluir la hora también esta estaría acotada por las letras “T” y “Z”, por ejemplo, si la hora fuesen las 11:26:24am, usaríamos la notación:
- 1989–12–13T11:26:24Z
Este formato es especialmente útil para realizar ordenaciones eficientes y para comunicar fechas entre distintos sistemas, ya que es un estándar bien conocido y cualquier lenguaje implementa el soporte para esta notación.
Conclusiones
Es conveniente que adoptemos esta práctica de forma habitual, ya que cuando un proyecto escala a nivel internacional, es más difícil realizar la adaptación, ya que tendremos millones de registros en base de datos con la zona horaria equivocada, y cientos de lineas de código que cambiar debido a que no tienen en cuenta la zona horaria.
Puede parecer más cómodo empezar sin tenerlo en cuenta, ya que la fecha que le pasemos al frontend es la que tiene que mostrar, sin conversiones ni nada que impida avanzar de forma rápida y sin engorros, pero como se suele decir: es pan para hoy y hambre para mañana.
Añadir esta práctica va a aportar mucho control a nuestras operaciones coordinadas y al crecimiento a medio/largo plazo de nuestro proyecto.
Top comments (0)