2011-04-14 13 views
5

Estoy buscando recomendaciones para mostrar los tiempos en una aplicación web en un huso horario que no sea el huso horario actual del usuario.¿Visualización de fecha y hora sensible a la zona horaria en aplicaciones web?

Almacenamos nuestras fechas/horas en UTC/GMT en la base de datos, por lo que no es un problema formatear la hora de UTC/GMT o la zona horaria actual del usuario. Sin embargo, en otras situaciones necesitamos mostrar el tiempo desde el punto de vista de una zona horaria arbitraria (es decir, cada fecha/hora en esta página está en el este, independientemente de si el usuario está o no en costa oeste, centro, este, etc.).

En el pasado hemos almacenado desplazamientos o información de zona horaria, luego hicimos los cálculos en el código del servidor en .Net o bien hicimos algunas manipulaciones del lado del cliente en JavaScript que preferiría evitar, ya que todo se vuelve muy depende de javascript y del navegador del usuario. Me gustaría saber la mejor manera de hacer esto en una aplicación de tipo MVC o más del lado del cliente.

Aquí se muestra un ejemplo:

  1. fecha almacenada en dB: 1302790667 (Jue 14 Abr 2011 14:17:47 GMT)
  2. fecha convertida se muestra para un cliente en la zona horaria central: Jue Abr 14 09:17:47 2011
  3. Fecha realidad quiero mostrar, siempre en la zona horaria del Este: Jue Abr 14 10:17:47 2011

en el ejemplo anterior, es fácil obtener la hora en UTC (n. ° 1) o la zona horaria actual del usuario (n. ° 2) pero es más difícil obtener el # 3. Mis opciones parecen ser:

  1. compensaciones tienda o zonas horarias en la base de datos y hacer cálculos en el cliente - esto es lo que hemos hecho en el pasado con .Net pero parece incluso más desordenado en el código del lado del cliente es el camino que estamos tratando de evitar
  2. Realice la conversión en el servidor y envíe una fecha completa para mostrar al cliente: el cliente recibe una cadena ("Thu Apr 14 10:17:47 2011"). Esto funciona pero no es muy flexible.
  3. Haga la conversión en el servidor, divídala en partes y envíelas al cliente, luego vuelva a armarlas. ("{DayOfWeek: Thu, Month: Apr, Day: 14, Hour: 10, Minute: 17}"). Esto nos da los datos correctos y nos da más flexibilidad en el formato de la fecha, pero se siente un poco mal en este escenario.

¿Alguna otra opción de ideas? ¿Cómo manejan los demás situaciones similares? Gracias.

+0

¿Qué terminaste usando? Estoy a punto de probar [esto] (https://github.com/csnover/js-iso8601), tengo el mismo requisito de cliente y estoy compitiendo con el reloj en este caso. – blong

+1

Terminamos haciendo todos los cálculos en el servidor. Añadiré una respuesta. –

Respuesta

0

Ofrezco la sugerencia de que busque en la biblioteca Datejs. Ofrece un conjunto de extensiones para la manipulación básica de fechas de JavaScript, incluido un método "setTimezone()" y formas flexibles de convertir una fecha en una cadena formateada para su visualización.

Normalmente dudo en sugerir bibliotecas cuando su uso no está explícitamente permitido en las preguntas, pero Datejs no es muy grande y es bastante sólido (aunque se llama versión "alfa"). Si prefieres no confiar en algo así, es posible que quieras verlo de todos modos solo para ver los conceptos básicos de cómo se implementaron sus extensiones.

1

Nuestros resultados:

  1. probé un par de librerías como Datejs, MS Ajax, etc., y nunca fui muy feliz con ellos.Datejs no funcionó en absoluto en algunos de mis casos de prueba, no se mantiene activamente, y parecía enfocarse mucho en el azúcar sintáctico que no necesitamos (date.today(). First(). Jueves(), etc.)
  2. Usamos jQuery para un análisis básico de fecha/hora.
  3. Encontré muchos "hackers" de conversión de fechas en el lado del cliente, la mayoría de los cuales solo abordaban la conversión a UTC, comenzaban a funcionar bien y eventualmente se desmoronaban en algunos casos extremos. This one fue la solución del 90% para muchas conversiones UTC estándar pero no resolvió nuestro problema de "zona horaria arbitraria".

Entre la complejidad del código agregado a las rutinas de conversión y los errores que parecían causar, decidimos evitar el procesamiento de fechas del lado del cliente la mayor parte del tiempo. Hacemos las conversiones de fecha en el servidor con nuestras rutinas de manejo de fechas existentes y pasamos las fechas formateadas o la información como propiedades para ser utilizadas por la vista. Si necesitamos una fecha separada, simplemente agregamos otra propiedad. Por lo general, solo hay unas pocas propiedades que necesitamos a la vez (es decir, EventDateUTC, EventDateLocal, EventDateAlwaysAustralia y EventDayOfWeek).

Cuestiones relacionadas