Formatos de fechas

Respuesta

El primer impulso puede ser asumir que el problema se resolverá durante el proceso de localización de las páginas web, es decir, dejar que lo resuelva el traductor. Resista ante este impulso. ¿Realmente desea mantener copias separadas de documentos para Estados Unidos y para el Reino Unido que simplemente tengan distintos formatos de fechas? En caso de que tenga que trabajar con usuarios plurilingües como en el ejemplo anterior,

existen tres opciones a tener en cuenta. Todas tienen ventajas y desventajas:

Usar un formato neutral para cuestiones lingüísticas regionales
Procurar que el mes y el año resulten evidentes
Utilizar el encabezado HTTP Accept-Language

Opción uno: usar un formato neutral para cuestiones lingüísticas regionales

La norma ISO 8601 especifica un formato AAAA-MM-DD. 2003-04-02 es más claro que 03/04/02. (Algunos prefieren modificar la norma ISO 8601 y utilizar una forma abreviada al indicar el mes para que resulte más claro, por ejemplo, 2003-abr-02. Sin embargo, esta variante ya no es neutral para cuestiones lingüísticas regionales).

Pros:

Este método es inequívoco.
La norma ISO 8601 resulta sencilla de aplicar. Simplemente ordenando los caracteres de una lista de fechas se obtiene una lista organizada cronológicamente.

Contras:

La norma ISO 8601 no resulta amigable para el usuario. El usuario se siente cómodo al utilizar su formato "natural" de fecha.
Ocupa más espacio. La fecha de un párrafo de texto no representa un problema. Si el documento es una tabla que contiene columnas con fechas, el espacio adicional puede convertirse en un problema, especialmente si se ha pensado un diseño que ya se encuentra limitado por temas de espacio.
Esta opción puede resultar particularmente complicada para usuarios de países donde se emplean calendarios alternativos (por ejemplo, en Tailandia donde tienden a usar el calendario budista).

Opción dos: procurar que el mes y el año resulten evidentes

Para hacerlo, utilice un nombre para el mes (en forma abreviada o no) y 4 dígitos para los años del calendario gregoriano. Por ejemplo, 2 de abril de 2003.

Pros:

Este método no presenta ambigüedades.
Resulta fácil para el usuario. El usuario se siente cómodo al utilizar su formato "natural" de fecha.

Contras:

No resulta tan intuitivo para la computadora cuando se trata de realizar ciertas tareas como ordenar elementos.
Ocupa más espacio. Para algunos estilos lingüísticos regionales, la abreviatura de un mes puede tener una extensión mayor de tres caracteres. (En francés, las primeras tres letras de los meses junio y julio son las mismas, juin y juillet). Preveer espacio adicional para esto agrava el problema del espacio.

Opción tres: utilizar el encabezado HTTP Accept-Language

El encabezado HTTP Accept-Language sólo especifica las preferencias de idioma del usuario, pero se utiliza habitualmente para establecer preferencias de estilos lingüísticos regionales.

Este método funciona adecuadamente para documentos web generados en forma dinámica cuando se debe insertar en una página una fecha proveniente de algún sistema de almacenamiento back-end, siempre que las expectativas del usuario en términos de formato de fecha sean claras. La conveniencia de esta alternativa es una cuestión que depende más del contexto lingüístico que simplemente de la configuración del navegador del usuario. Por ejemplo:

Insertar una fecha desde una base de datos en una página en japonés en formato japonés resultaría muy útil para el usuario.
Un japonés que lea la fecha 03/04/02 generada en un documento en inglés podría asumir erróneamente que se siguió el orden del formato inglés.
Mostrar en una página en inglés una fecha generada en formato de fecha japonés, por ejemplo, ２００３年４月２日, probablemente se vería extraño.

La manera de resolverlo dependerá del entorno de desarrollo. A continuación se incluyen sugerencias para algunos entornos comunes.

Java/JSP

Llamar al método getLocale del objeto ServletRequest o HttpServletRequest. Utilizar el objeto devuelto Locale para llamar al DateFormat. Se debe tener en cuenta que en el formato SHORT (abreviado) únicamente se utilizan números. Si desea un formato sin ambigüedades, utilice el formato FULL (completo). Para algunos estilos lingüísticos regionales, aun el formato LONG (extenso) es completamente numérico.

Consulte también ICU4J, ya que contiene datos más actualizados (y más funcionalidades) que las rutinas JDK.

ASP

Usar Request.ServerVariables("HTTP_ACCEPT_LANGUAGE") para acceder a las preferencias del usuario. Analizar la sintaxis de los primeros estilos lingüísticos regionales de la lista de parámetros aceptados. Tendrá que hacer su propia conversión del código alfabético del estilo lingüístico regional a un Identificador numérico de estilos lingüísticos regionales. Configurar Session.LCID según el valor resultante. Llamar a FormatDateTime para establecer el formato de la fecha.

Usar vbLongDate para evitar ambigüedades.

Perl

Usar $ENV{"HTTP_ACCEPT_LANGUAGE"} para acceder al idioma de preferencia. Usar POSIX:strftime para dar formato a los valores de fechas. Tendrá que hacer su propia conversión del valor de los idiomas aceptados a una secuencia de formatos de fechas.

Resumen

No existe una solución ideal para este problema. Se deben evaluar las opciones y seleccionar la alternativa más adecuada según sus preferencias y su situación particular.

Si considera que los datos pueden resultar ambiguos para el usuario, siempre es preferible emplear nombres explícitos para referirse a los meses y cifras de cuatro dígitos al indicar los años para fechas en formato gregoriano o, al menos, indicar en la página cómo se deben leer las fechas.

Es posible volver a formatear las fechas mediante el empleo de técnicas dinámicas para lograr una correspondencia con el contexto lingüístico de la página.