2011-03-22 10 views
6

Estamos utilizando un selector de fecha jQuery en nuestro sitio web para seleccionar fechas y horas para reservas. El calendario se establece actualmente en PST y esto causa errores cuando los usuarios intentan acceder desde otras zonas horarias. ¿Deberíamos configurar el servidor para que sea UTC y hacer que la aplicación seleccione automáticamente la zona horaria del usuario según su dirección IP? Tenía curiosidad acerca de si también deberíamos incluir la selección manual ya que la selección automática puede fallar (es decir, cuando el usuario trabaja a través del proxy). Cualquier consejo sería muy apreciado.selector de fecha jQuery - TimeZone Issue

Respuesta

2

Me atrevo a adivinar que la interfaz no necesita tener NINGUNA comprensión de las zonas horarias en absoluto.

Cuando seleccionan una hora del datepicker, simplemente pásenla nuevamente como está (si seleccionaron las 9PM, simplemente pasaron las 9PM). En el servidor, convierta esa fecha a & en una marca de tiempo.

En ese momento, puede realizar ajustes para la zona horaria del usuario en función de IP, o como quiera implementarlo. Puede simplemente sumar o restar horas de su tiempo objetivo para que coincida con la zona horaria del usuario.

Sin embargo, esto significa que también deberá volver a analizar los momentos en que los muestra para asegurarse de que se muestren como deberían. Por lo tanto, si está almacenando una marca de tiempo Unix, por ejemplo, asegúrese de imprimir una fecha formateada según la ubicación del usuario.

Definitivamente debe permitir que el usuario elija su propia zona horaria para anular, sin embargo, lo hace de forma predeterminada.

7

El usuario ya selecciona su zona horaria que está en su configuración de sistema operativo. Use javascript to detect this timezone (not based on IP), y páselo junto con el valor del selector de fecha a la aplicación del servidor. Puede convertir la hora local a hora UTC en Javascript o en el lado del servidor, según prefiera. Pero mantenga la aplicación del servidor en UTC, ya que es una buena práctica e internamente eso es lo que algunos lenguajes usan, por ejemplo, java.util.Date en Java.

1

Si sólo necesita mostrar veces en la interfaz web:

  • tiempo de cálculo en el cliente como segundos (tiempo Unix) usando date.getTime()/1000; respectivamente Date.setTime (utc_seconds * 1000); en cuenta que Javascript utiliza milisegundos
  • transmisión todo momento entre el cliente y el servidor como segundos (tiempo Unix) Tiempo de
  • tienda como marcas de hora UTC (lo más probable es que su back-end soporta la conversión a una marca de hora UTC)

Si necesita hacer otras cosas en el servidor con tiempo legible para los humanos (por ejemplo, enviar un correo electrónico que incluya una hora de reunión):

  • capturar la zona horaria en el cliente (ej.usando jsTimezoneDetect) y guardarlo en el servidor
  • utilizar la zona horaria capturado para los cálculos del lado del servidor para el usuario

Advertencias:

  • sin importar el mecanismo, la detección de ubicación basada en IP es imperfecto; No lo usaría para la detección de zona horaria
  • la mayoría de los sistemas que no son de Windows usan el tz database; si su back-end es Microsoft, puede necesitar convert para las zonas horarias estándar de Windows
  • mientras la detección de zona horaria aumenta, las cosas pueden salir mal, ya que algunas jurisdicciones cambian las zonas horarias ad hoc;
  • para su aplicación, predigo la mayor parte del dolor en los cambios de las reglas de zona horaria si admite reuniones recurrentes; Los SO suelen incluir esto en los service packs
  • Puede considerar un mecanismo para que el usuario configure manualmente la zona horaria (posiblemente después de la autodetección)
Cuestiones relacionadas