A diario tratamos con fechas y horas. Cuando se trata del desarrollo web, las puedes ver en aplicaciones móviles, en correos electrónicos, en tus aplicaciones de mensajería y en muchos otros lugares. Sin embargo, a pesar de ver fechas y horas todos los días y en todas partes, aún no contamos con un formato único e universal.
Por ejemplo, si escribo 05/10/2015, nunca podrás estar seguro de si ese "10" es el mes o el día, a menos que te diga de dónde soy. Unas veces el cambio de formato, otras veces el lenguaje...
Es muy importante que como desarrolladores web prestemos atención a las fechas y horas con las que trabajamos en nuestros proyectos, atendiendo a la diferentes zona geográfica de nuestros visitantes para no ocasionar ningún conflicto. En este artículo vamos a discutir sobre lo que se debe evitar y lo que debemos de adoptar cuando tratamos de mostrar fechas y horas.
Globalización
Digamos que no queremos convertir y mostrar diferentes formatos de fecha y hora a los diferentes visitantes de nuestra web de todo el mundo, ¿qué podemos hacer? Pues no nos queda otra que escoger un formato global. Aquí es donde los estándars entran en juego. Antes de llegar a eso, os tengo que decir que W3C recomienda usar el formato de fecha ISO 8601 con la zona horaria UTC.
ISO 8601
ISO 8601 describe una manera internacionalmente aceptada para representar fechas y horas utilizando números.
Y el formato de la fecha completa es YYYY-MM-DD, por ejemplo: 2016-09-08
YYYY = Año con cuatro dígitos
MM = Mes con dos dígitos (01 = Enero, etc.)
DD = Día con dos dígitos (del 01 al 31)
Para fecha y hora completa sería YYY-MM-DDThh:mm:ss.s, por ejemplo: 2016-09-08T18:00:18.45
T = Para separar fecha de hora de acuerdo al ISO 8601
mm = Minutos con dos dígitos (del 00 al 59)
ss = Segundos con dos dígitos (del 00 al 59)
s = Fracción decimal de un segundos. 1 o más dígitos.
Ten en cuenta que no hemos mencionado la zona horaria en el ejemplo anterior, por lo que es de suponer que se hace uso de la zona horaria local. Si has decidido utilizar la zona horaria UTC, sólo tienes que añadir Z al valor para denotar UTC.
Por ejemplo: 2016-09-08T18:00:18.45Z
De todas maneras, si quieres mostrar la hora local, puedes añadir un ajuste de zona horaria para UTC al valor en los formatos +hh:mm o -hh:mm, según sea necesario.
Por ejemplo, supongamos que 2016-07-28T21:15:18.45 es en la zona horaria es EST (Eastern Standard Time) cuya diferencia horaria con la UTC es de 5 horas.
Para representar la diferencia con UTC escribimos 2016-07-28T21:15:18.45-05:00, que es el equivalente a la hora UTC 2016-07-29T02:15:18.45Z.
De nuevo, pon Z para indicar que la fecha y la hora que se muestra es en UTC.
UTC vs GMT
Ambos son lo mismo, pero diferente. Es probable que te hayas topado con GMT alguna vez. Seguro que al introducir la fecha-hora en tu teléfono móvil o en tu ordenador. Es la zona horaria más popular en todo el mundo, y es mucho más antiguo que UTC.
Mucha gente puede decir que son lo mismo, pero no es así. UTC es sucesor directo de GMT y está mantenido por la Unión Internacional de Telecomunicaciones. Se aconseja para referirse al tiempo, basarse en UTC y no en GMT.
Uso del nombre de los meses
El estándar ISO solo utiliza números en la representación de fechas para evitar cualquier conflicto lingüístico. Pero, si el contenido de la aplicación web va a estar en inglés, deberás considerar la posibilidad de escribir los meses en inglés en lugar de en números.
En lugar de 28/07/2016, 28, July de 2016 es más fácil de entender por muchos, y menos confuso.
Localización
Hay momentos en que queremos ser muy específico con nuestros servicios y nos gustaría representar la fecha y la hora en las distintas zonas horarias e idiomas locales. Hay muchas librerías y APIs disponibles para desarrolladores web que brindan la oportunidad de mostrar las fechas y las horas como procede por la región por la que accedes.
Se puede obtener la configuración regional predeterminada del navegador, ya sea mediante la interpretación de la cabecera Accept-Language o a través de los objetos de Javascript navigator.language o navigator.browserLanguage. Pero el mejor método es permitir al usuario elegir una configuración regional en su aplicación, ya que los otros métodos no son muy fiables.
Una vez tengas la configuración regional, puede darle formato a la fecha y a la hora de acuerdo a la configuración. Por ejemplo, mediante la Internationalization API, puedes darle formato a una fecha con toLocaleDateString en JavaScript. Por ejemplo, myDate.toLocaleDateString( 'ko-KR') devolverá un fecha formateada en el formato utilizado en Corea por los nativos de habla coreana.
Horario de verano
En algunos países, como en España, el horario de verano se realiza adelantando los relojes una hora en verano para hacer uso de la luz solar disponible. Estate atento al horario de verano para mantenerte al día con los tiempos locales en tus servicios.
No utilices dos dígitos para los años
Bajo ningún concepto, nunca utilices dos dígitos para las fechas en tus desarrollos. Por favor, ya estamos en el siglo 21. Utilizar años como 64, 99, etc. te ocasionarán problemas en el futuro. Si cuentas con un sistema de dos dígitos para los años, considera el cambio.
Año bisiesto y otros calendarios
Vamos a terminar este artículo con ciertas cosillas a recordar al tratar con fechas. Si no está usando ninguna librería o API para fechas y quieres tratar con ellas por tu cuenta (cosa que no recomendamos), no olvides mostrar el 29 de febrero cuando el año sea bisiesto.
Además, vale la pena señalar que el calendario gregoriano no es la única forma de calendario disponible y utilizado en todo el mundo. No estaría de más que te informases sobre ello.
Fuente: hongkiat.com