Fechas para recordar. Sobre el formato de las fechas

Reloj astronómico

Vivimos en un mundo cada vez más conectado y global. La comunicación de datos tiene cada vez más importancia en todos los órdenes de la vida como en transacciones comerciales, contratos, datos de investigación científica, actividades sociales, por poner sólo unos ejemplos. Nuestra civilización ha hecho adelantos significativos en los estándares de medidas como el Sistema Métrico Decimal. Hasta el tradicional Reino Unido abandonó sus antiguos peniques y chelines para hacerlos decimales. Estados Unidos de Norteamérica aún se resiste y sigue usando sus antiguas medidas de longitud, capacidad y masa.
Pero hay un problema universal en el que nos cuesta ponernos de acuerdo. Es la representación del tiempo. Las fechas son muy importantes no solamente desde el punto de vista histórico o de registro, sino también para efectos de contractuales y de cálculo.  El problema es que en distintos países el uso y la costumbre hacen que se escriban las fechas de un modo que resulta ambiguo para el resto del mundo no advertido de su convención. Podemos ver las costumbres de representación de fechas en distintos países en la Wikipedia.
Por ejemplo, la fecha en que escribo este post, 7 de Mayo de 2013, en muchos países de Europa se representaría como 07/05/2013 (DD/MM/YYYY). Pero esta representación en Estados Unidos significa el 5 de Julio de 2013 (MM/DD/YYYY).  Esto es un verdadero problema especialmente para las fechas cuyos días son menores que 13, pero también complica mucho el software que tiene que registrar, almacenar, procesar y mostrar fechas. Podemos eliminar la ambigüedad si representamos el mes por su nombre completo o abreviado, como en 07-May-2013 o en May 7,2013. Sin embargo esto no elimina el problema de que la representación de la fecha debería ser localizada para el país del usuario de la aplicación, tanto por la necesidad de traducir los nombres de los meses como por el formato de la fecha en sí.
La representación de las horas también tienen su historia. Aunque todos utilizamos las horas, minutos y segundos, hay países que en lugar de utilizar el rango de 24 horas usan el de 12 añadiendo AM o PM para indicar si es antes o después del mediodía.
Para solucionar estos problemas se ha creado un estándar internacional, la norma ISO 8601 que especifica una forma numérica no ambigua de representar fechas y horas. Esta norma data de 1988 y su última revisión ha sido en el 2004. Otras normas internacionales recogen este mismo estándar como la Europea EN 28601 adoptada en España. La norma establece que las fechas deben representarse del siguiente modo:
YYYY-MM-DD 2013-05-07 para la fecha solamente
HH:MM:SS 14:03:35 para la hora solamente
YYYY-MM-DDThh:mm:ss 2013-05-07T14:03:35 o bien
YYYY-MM-DD hh:mm:ss 2013-05-07T14:03:35 para fecha y hora
Observemos que la representación es de tipo “big endian“, es decir que de izquierda a derecha se representa desde la parte más significativa, el año, hasta la parte menos significativa, los segundos. Los separadores deben ser exactamente los indicados y sólo en el caso de la separación entre fecha y hora se admite que se utilice un espacio en blanco en lugar de la “T” para aumentar la legibilidad. Puede haber representaciones parciales de la fecha o de la hora pero respetando el orden. Por ejemplo:
2013 el año 2013
2013-05 el mes de Mayo de 2013
La norma establece que cada componente de la fecha y hora debe ponerse con los dígitos indicados, con ceros precedentes cuando sea necesario. Por ejemplo:
13-05-07 incorrecto, el año debe tener 4 dígitos
2013-5-7 incorrecto, el mes y el día deben tener 2 dígitos
2013-05-07 correcto
14:3:35 incorrecto, HH, MM y SS deben tener 2 dígitos
02:03:35pm incorrecto, la hora debe ser en 24 horas
14:03:35,264 correcto, más precisión con fracciones de segundos que pueden estar separados por punto o por coma.
Además se contempla la representación de la información de zona horaria. Ejemplos:
13-05-0 14:03:35Z Hora UTC (Universal Time Coordinated). Si no se especifica la “Z” se supone que la hora es local pero no se especifica la zona
13-05-07 14:03:35+02:00 Hora UTC+2
Además de ser una representación no ambigua del tiempo, el formato ISO 8601 tiene muchas ventajas.
  • Tiene el mismo tratamiento lógico que hacemos con las cantidades numéricas, poniendo las cifras más significativas primero (big endian).
  • No requiere traducción ni localización alguna.
  • En una lista ordenada por fechas, como en los movimientos de una cuenta bancaria, o en un log de eventos, es mucho más fácil, intuitivo y rápido buscar visualmente una fecha determinada en este formato.
  • Si un archivo de texto tiene formato de tabla donde una de las columnas es una fecha, entonces es mucho más fácil de ordenar y dividir mediante las utilidades convencionales como el programa sort.
  • Las fechas expresadas en este formato son fácilmente comparables, ya que el problema de determinar cuál es mayor que otra es una comparación simple.

Tenemos que exigir a las aplicaciones que seleccionamos que sean capaces de aceptar y mostrar las fechas y horas en formato ISO 8601 para que la globalización no nos pille de sorpresa. Recordemos que aunque no haya usuarios que utilicen nuestra aplicación en otros países, si enviamos una factura a otro país donde se usa otro formato de fecha, podemos incurrir en una ambigüedad que podría tener consecuencias.   Cada vez hay más aplicaciones que utilizan de manera predeterminada el formato ISO 8601.

Un caso a considerar es la estrategia a adoptar si tenemos que desarrollar una aplicación que vaya a ser utilizada simultáneamente por usuarios que están en lugares con distintas zonas horarias. En este caso debemos ser muy cuidadosos con las fechas y horas porque podría haber muchas confusiones. Imaginemos un servicio de atención al cliente que está externalizado en otro país o es atendido por un equipo internacional cuyos integrantes están en distintos países y entran en servicio acompañando el día. Ellos necesitan tener en cuenta su hora local pero también la hora local del cliente y quizás la hora de otro equipo que le atendió anteriormente. La mejor estrategia para tratar este problema es observar estas 3 reglas:

  1. Establecer la zona horaria del usuario. Puede estar en su perfil y él puede cambiarla a voluntad. Cada vez que ingrese una fecha y hora, la aplicación entiende que están en la hora local configurada en ese momento.
  2. Convertir y almacenar todas las fechas y horas en UTC
  3. Al mostrarlas, convertirlas a la hora correspndiente a la zona que el usuario que las visualiza tenga configurada.

Otra aplicación del formato ISO 8601 es para construir nombres de archivos que queden ordenados lógicamente cuando listamos el directorio. Por ejemplo, si semanalmente escribimos un documento que es el acta de una reunión, podemos nombrar al archivo como

ActaReunión_2013-05-06.doc

Las actas de las sucesivas reuniones quedarán juntas y ordenadas por fecha aunque veamos el directorio en orden alfabético, que es lo habitual.

Personalmente, siempre que no estoy obligado a lo contrario utilizo las fechas en formato ISO 8601 desde hace unos 6 años, inclusive para mis notas personales. No tuve mayores dificultades en adaptarme y al poco tiempo me ha resultado una forma más natural de escribir una fecha. Si fechamos un contrato o acuerdo con alguien de otro país es muy importante especificar la fecha de forma no ambigua, como lo señala esta web, porque de lo contrario podría tener consecuencias desfavorables en caso de litigio.

Adoptar el estándar internacional en el software, en nuestros contratos y escritos es hacer una apuesta segura por la internacionalización facilitando la comunicación entre las personas y entre los sistemas de información, porque hay que recordar que no vivimos solos.

Referencias

No se aceptan nuevos comentarios.