it-swarm.dev

¿Cómo puedo manejar las zonas horarias en mi aplicación web?

Estoy buscando una mejor comprensión de la siguiente historia de usuario:

John trabaja en Sidney. A las 9:00 de la mañana, registra un evento en una aplicación web que se ejecuta en un servidor en Zurich. Al día siguiente, viaja a Nueva York para una reunión de emergencia en la que se debe discutir el evento. Durante la reunión, busca el evento por fecha y hora.

Como yo lo veo, hay al menos dos problemas aquí:

  1. ¿Cómo debo guardar las marcas de tiempo en la base de datos?
  2. ¿Cómo debo presentarlos en la interfaz de usuario?

Cuando John busque el evento, sabrá que sucedió a las 9:00, pero ¿qué debería ingresar en el navegador web? No encontrará nada cuando solo ingrese "9:00" como marca de tiempo porque podría ser la hora de Zúrich o Nueva York (ya que el evento no se ha encontrado, la aplicación no tiene forma de saber que sucedió en Sidney, así que no puede seleccionar automáticamente la zona horaria correcta).

¿Cuál es una buena manera de pedirle al usuario una marca de tiempo que podría incluir la zona horaria?

El segundo problema es cómo mostrar los resultados. Si equipos de todo el mundo necesitan discutir el evento (y encontrar eventos relacionados, piense en un ataque pirata que tenga como objetivo varios sitios en todo el mundo a la vez).

¿Cuál es un buen ejemplo para mostrar las marcas de tiempo que se podrían haber creado en una zona horaria diferente?

Nota: Por favor concéntrese en la usabilidad del requisito. Puedo averiguar el mapeo de la base de datos yo mismo. Actualmente, no estoy seguro sobre el flujo de trabajo. Debe solicitar/presentar la información necesaria de forma no intrusiva/intuitiva. Si puede, proporcione un enlace a una aplicación web existente que ya resuelva esto.

88
Aaron Digulla

El problema de almacenar las marcas de tiempo es simple: Almacénelas en UTC.

En cuanto a mostrarlos, tendría sentido tomar la configuración de zona horaria del dispositivo y usarla como la zona horaria actual. Dicho esto, debería haber un menú desplegable de zona horaria junto al cuadro de "entrada de tiempo", que se establece de manera predeterminada en la zona horaria actual del dispositivo, de modo que el usuario pueda cambiarlo si es necesario.

La mayoría de los usuarios probablemente no cambiarán mucho las zonas horarias, o en absoluto. En su mayor parte, la situación que describió es poco común. Al implementar un menú desplegable con un valor predeterminado adecuado, debería poder facilitar las cosas para aquellos que sí se mueven (porque normalmente tienen una mejor comprensión de las zonas horarias de lo que lo haría un no viajero).

De hecho, incluso mejor sería guardar la zona horaria en la que se configuró el dispositivo cuando se ejecutó la aplicación por primera vez, y luego ver si alguna vez cambia. Si cambia, entonces el usuario probablemente sea un viajero y probablemente se beneficiaría de tener el menú desplegable de zona horaria. De lo contrario, simplemente no muestre el menú desplegable y el valor predeterminado en la zona horaria del dispositivo (porque el usuario no necesita saber sobre ellos). En cualquier caso, tenga una configuración en la aplicación que le permita al usuario mostrar/ocultar manualmente el menú desplegable de la zona horaria.


Para resumir lo anterior:

  • En la primera ejecución, guarde en qué zona horaria está configurado el dispositivo.
  • Utilice esa zona horaria como la zona horaria predeterminada. Siempre asume esa zona horaria.
  • En caso de que el dispositivo cambie las zonas horarias, agregue un menú desplegable para seleccionar en qué zona horaria se encuentra el evento, de manera predeterminada a la zona horaria propia del dispositivo.
  • Agrega una opción para mostrar/ocultar este desplegable de zona horaria manualmente.
  • Siempre almacene las marcas de tiempo en UTC.
83

En nuestras aplicaciones, generalmente almacenamos la zona horaria del usuario cuando nos registramos por primera vez, como se ve a menudo en los sitios del foro, y siempre muestra la hora con la zona horaria .

En cuanto al almacenamiento de las fechas, UTC es el camino a seguir. Convertir a UTC y pegarlo en la base de datos. Mientras se recupera, simplemente convierta el tiempo a la zona horaria establecida para el usuario.

Tuve que resolver un caso de uso similar, donde se podían enviar notificaciones personalizadas, como "Feliz Año Nuevo", a todos los usuarios de la aplicación web. Dado que los usuarios se extienden por todo el mundo, necesitamos mostrar la notificación de acuerdo con la zona horaria. El almacenamiento de la marca de tiempo en UTC sirvió muy bien nuestro propósito, sin contratiempos.

En su caso de uso, si no está almacenando la zona horaria del usuario en algún lugar, nunca podrá devolver con precisión sus resultados de búsqueda sin solicitar la entrada del usuario, a menos que comience a usar algún tipo de detección de ubicación como lo hace gmaps, pero no es así. t confiable Por lo tanto, deberá solicitar la zona horaria cada vez que se asegure de que el usuario sepa lo que está ingresando en el sitio web.

Si tiene información de la zona horaria, toda la aplicación web debe ejecutarse con la configuración de la zona horaria. Por lo tanto, cuando el usuario busca las 9:00, buscará con la zona horaria de Sydney. Por otro lado, si crea un evento mientras está sentado en Nueva York, creará un evento con la zona horaria de Sydney. Resolvemos estos casos mostrando siempre la zona horaria mientras mostramos las fechas.

¡Espero eso ayude! :)

19
Varun Achar
  1. UTC. Mantenlo simple.

  2. Utilice la zona horaria que sea más relevante para el usuario.

    Si sabe que el usuario va a estar o viajará a Sydney para el evento, entonces estará pensando en esa zona horaria cuando organice el transporte al evento. El hecho de que estén actualmente en Nueva York es en gran medida irrelevante. Y, por supuesto, si su aplicación muestra fechas en una variedad de zonas horarias, siempre debe mostrar la zona horaria al lado de la fecha, por ejemplo. 09:00 EST .

    Si no se desordena demasiado su interfaz, puede mostrar las fechas en la zona horaria del evento y la zona horaria local, por ejemplo. 2012-06-13 09:00 EST (2012-06-12 19:00 EDT) .

    Yo diría que la búsqueda es un problema similar, con una advertencia: podemos tolerar falsos positivos (obteniendo un resultado que no esperábamos), pero no podemos soportar falsos negativos (no obtenemos un resultado que esperábamos).

    Una vez más, me centraré en buscar la zona horaria más relevante para el usuario (por ejemplo, la zona horaria del evento), y daré prioridad a estos resultados en los resultados de búsqueda, pero también puede devolver eventos que coincidan en otras zonas horarias que sean relevantes para el usuario (por ejemplo hora local). Si hace esto, debe mostrar la fecha del evento en la zona horaria correspondiente, especialmente si resalta el texto correspondiente.

10
Richard Poole

Aquí estoy dando sugerencias para una mejor usabilidad sin preocuparme mucho por la factibilidad de la implementación.
1. Para el primer número de almacenamiento de eventos en db, todos estarían de acuerdo en almacenarlo en UTC

2. Para brindar la mejor experiencia de usuario, guarde el historial de la zona horaria del usuario. Si pudiera guardar la marca de tiempo del cambio de zona horaria, aún mejor. Esto nos permitirá dar libertad al usuario para realizar consultas sin especificar explícitamente la zona horaria cada vez.

Entonces, con estas características, veamos cómo se manejará la consulta de búsqueda de solo "9.00" de John:
Con las características mencionadas anteriormente, ahora sé que John ha estado en 2 zonas horarias hasta la fecha (u obtener la lista de zonas horarias para el período mencionado). Así que convertiré 9.00 desde la zona horaria de Sydney a UTC, dispararé una consulta. También convierta 9.00 de la zona horaria de NewYork a UTC, active una consulta. En el resultado, le mostraré 2 filas a John mostrando lo que hizo a las 9:00 en Sydney y a las 9:00 en Nueva York. La línea de Nueva York estará en blanco en este caso, pero creo que aún debería mostrarse al usuario, solo para informarle que también buscamos esta zona horaria.

3. ¿Cuál es una buena manera de pedirle al usuario una marca de tiempo que podría incluir la zona horaria?

Si su zona horaria ha cambiado recientemente, cada vez que inicie sesión en una aplicación, se le debe dar una notificación de que su zona horaria predeterminada se cambia a la zona horaria nativa.
Al crear un evento, digamos que el usuario selecciona la zona horaria de la lista desplegable. No carga al usuario dando opciones de todas las zonas horarias del mundo. La primera opción de la lista desplegable debe ser la zona horaria actual del dispositivo del usuario. después de esas zonas horarias de su historial de zonas horarias, luego UTC y luego las zonas horarias restantes que nunca ha usado hasta la fecha.

4. Cómo mostrar los resultados, si los equipos de todo el mundo necesitan discutir el evento:

Me gustaría dividir este caso de uso entre el número de equipos 2 o más de 2.
Para solo 2 equipos, preferiría que cada equipo vea la marca de tiempo en su zona horaria local y la zona horaria de otro equipo. (Personalmente prefiero hablar en la zona horaria de la persona en el otro extremo para su conveniencia al programar una reunión). Para más de 2 equipos, es mejor considerar una zona horaria más común, es decir, UTC. Entonces, en este caso, cada usuario debe ver la marca de tiempo en 2 zonas horarias, en UTC y en su zona horaria predeterminada.

Estas sugerencias se dan con la intención de que el usuario no tenga que hacer ningún cálculo en su hora local, pero al mismo tiempo debe poder comunicarse con otros usuarios con fluidez en su zona horaria preferida.

7
Pranalee

Ok tengo un enfoque diferente a los demás:

En primer lugar, asumí pocas cosas de antemano.

La persona que está listando un evento tiene un teléfono inteligente (si es un navegador, no tengo que hacer estas suposiciones) con:

  1. GPS

  2. Capacidad HTML5.

  3. Capacidad de Javascript

¿Cómo debo guardar las marcas de tiempo en la base de datos?

Solución: ObviamenteUTC, superpuse el procedimiento a continuación:

Paso 1. Usa la Geolocalización del usuario usando la API de Geolocalización

    window.onload = getMyLocation;

    function getMyLocation() {
        if (navigator.geolocation) {
            navigator.geolocation.getCurrentPosition(displayLocation);
        } else {
            alert("Oops, no geolocation support");
        }
    }

    function displayLocation(position) {
        var latitude = position.coords.latitude;
        var longitude = position.coords.longitude;
        var div = document.getElementById("location");
        div.innerHTML = "You are at Latitude: " + latitude + ", Longitude: " + longitude;
    }

Paso 2. Ofrezca los argumentos (Long, Lat) a algunos de los (Lat, Long) a TimeZone api como el Yahoo API (use Flag R para obtener la latitud convertida en Timezone) para obtener la zona horaria de los usuarios.

=> La zona horaria de los usuarios se determina sin la entrada del usuario (Estoy usando esto porque no se puede asumir simplemente que el usuario conoce la zona horaria del lugar en el que vive, conocí mi zona horaria solo después de algunos meses o algo así en el lugar : P, bastante tonta!)

La tabla de cada Evento tiene Timezone, Event y también puede tener CityName Luego cree otra tabla de base de datos con clasificación basada en CityNames. Así que aquí el usuario tendrá dos columnas.

|---------------------------------------|
|_____NewYork________|______Sydney______|
|                    |                  |
|Event 1             |  Event 2         |
|____________________|__________________| 

Para la interfaz de usuario

=> usar la API de Google Calendar o algunas de las API de Calendar

Lecturas relacionadas:

  1. Determine la zona horaria de latitud/longitud sin usar servicios web como Geonames.org

  2. Búsqueda de zona horaria desde latitud longitud

Sé que solo se trata de mostrar una idea de cómo resolver este problema. Pero vea cuán precisa y liviana se vuelve para los usuarios cuando la Zona horaria se determina mediante el uso de API de dispositivo

¡Espero eso ayude!

4
uday
  1. ¿Cómo debo guardar las marcas de tiempo en la base de datos?

Al crear el evento, almacenaría la hora UTC y la zona horaria local (también conocida como creation time zone). Usaría lo que almacené para convertir la hora UTC en hora local (también conocida como creation time) y la almacenaría junto con la hora UTC y creation time zone.

NOTA: Puedo almacenar la hora local desde el primer momento, pero cuando el usuario realiza una búsqueda de un evento, espero que exista una conversión a la hora local. También espero que el servidor pueda detectar en qué zona horaria se encuentra el cliente.

  1. ¿Cómo debo presentarlos en la interfaz de usuario?

Cuando un usuario busca "9:00", buscaría eventos que incluyan "9:00" en UTCOcreation timeOhora local. Para los resultados, mostraría una tabla de resultados en creation time (con la intención de mostrar las marcas de tiempo que pueden haber sido creadas en una zona horaria diferente, ya que asumimos que el usuario está buscando a qué hora creó un evento donde sea que esté. ), y muestre una segunda tabla de resultados a continuación con los resultados relacionados, tal vez con el encabezado "¿No es lo que está buscando? Vea los resultados relacionados" (esto incluye el UTC restante y los resultados de la hora local).

En general, mostraría la hora UTC, la hora local, el creation time y el creation time zone (es decir, la hora local y la zona horaria del evento donde se creó) ordenados por la hora UTC, para que pueda ver qué evento es el primero, en caso de que Se programaron dos eventos diferentes para las 9:00 en dos zonas horarias diferentes.

2
user5398447

Para ese caso particular, almacenaría tanto local como UTC. UTC es un tanto importante y se usa para sincronizar y convertir la hora a la zona horaria actual. Local se usa para búsquedas y para información adicional, como:

Tienes una reunión:

12:00 Monday (UTC)
9:00 Monday (Sydney, creation local time)
11:00 Monday (Zurich, local time)

o algo así. La otra forma es almacenar la zona horaria de creación y convertir en tiempo de ejecución (esto es particularmente mejor en caso de que el usuario cambie el tiempo de reunión). De cualquier manera, la razón principal es poder restaurar el tiempo de creación original para que el usuario pueda consultarla.

2
Petr Abdulin