web applications - ¿Cómo puedo manejar las zonas horarias en mi aplicación web?
web-applications timezone (7)
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 debatirá el evento. Durante la reunión, busca el evento por fecha y hora.
Según lo veo, hay al menos dos problemas aquí:
- ¿Cómo debo guardar las marcas de tiempo en la base de datos?
- ¿Cómo debería presentarlos en la interfaz de usuario?
Cuando John busque el evento, sabrá que ocurrió a las 9:00, pero ¿qué debería ingresar en el navegador web? No encontrará nada cuando ingrese "9:00" como marca de tiempo porque podría ser hora de Zurich o Nueva York (dado que el evento no se ha encontrado, la aplicación no tiene forma de saber que sucedió en Sidney, por lo 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 pueda incluir la zona horaria?
El segundo problema es cómo mostrar los resultados. Si los equipos de todo el mundo necesitan debatir sobre el evento (y encontrar eventos relacionados, piense en un ataque de cracker que se dirija a varios sitios en todo el mundo a la vez).
¿Cuál es un buen ejemplo para mostrar las marcas de tiempo que podrían haberse creado en una zona horaria diferente?
Nota: Por favor concéntrese en la usabilidad del requisito. Puedo resolver el mapeo de la base de datos yo mismo. Actualmente, no estoy seguro del flujo de trabajo. Debe preguntar / presentar la información necesaria de una manera no intrusiva / intuitiva. Si puedes, dale un enlace a una aplicación web existente que ya resuelve esto.
- ¿Cómo debo guardar las marcas de tiempo en la base de datos?
En la creación del evento, almacenaba la hora UTC y la zona horaria local (también conocida como creation time zone ). Utilizarí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 la creation time zone .
NOTA: Puedo almacenar la hora local desde el inicio, 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.
- ¿Cómo debería presentarlos en la interfaz de usuario?
Cuando un usuario busca "9:00", busco eventos que incluyan "9:00" en UTC O creation time O hora local. Para los resultados, mostraría una tabla de resultados en el creation time (Esto tiene la intención de mostrar las marcas de tiempo que pueden haber sido creadas en un huso horario diferente, ya que suponemos que el usuario está buscando a qué hora creó un evento para donde sea .), y muestre una segunda tabla de resultados a continuación con resultados relacionados, tal vez con el encabezado "No es lo que está buscando" Vea los resultados relacionados "(estos incluyen los resultados UTC sobrantes y hora local).
En general, mostraría la hora UTC, la hora local, la creation time y la creation time zone (es decir, la hora local y la zona horaria del evento donde se creó) ordenadas por hora UTC, para que pueda ver qué evento es primero , en caso de que se programaran dos eventos diferentes para las 9:00 en dos zonas horarias diferentes.
UTC. Mantenlo simple.
Use la zona horaria que sea más relevante para el usuario.
Si sabe que el usuario va a estar o viajará a Sídney para el evento, entonces estará pensando en esa zona horaria cuando organice el transporte hasta el 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 junto a la fecha, por ejemplo, 09:00 EST .
Si no satura demasiado su interfaz, podría 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 (sin obtener el resultado que esperábamos).
De nuevo, me centraría en buscar la zona horaria más relevante para el usuario (por ejemplo, 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 coincidente.
Aquí estoy dando sugerencias para una mejor usabilidad sin preocuparme demasiado por la viabilidad de la implementación.
1. Para la primera edición de almacenamiento de eventos en db, todos acordarían almacenarlo en UTC
2. Para brindar la mejor experiencia de usuario, guarde el historial de la zona horaria del usuario. Si puede guardar la marca de tiempo del cambio de zona horaria, aún mejor. Esto nos permitirá dar libertad al usuario para consultar sin especificar la zona horaria explícitamente 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 obtenga la lista de zonas horarias para el período mencionado). Así que encubriré las 9.00 desde el huso horario de Sydney a UTC, desencadenaré una consulta. También convierta 9.00 de la zona horaria de NewYork a UTC, ejecute una consulta. En resultado mostraré 2 filas a John mostrando lo que hizo a las 9.00 en Sydney ya las 9.00 en Nueva York. La línea de Nueva York estará en blanco en este caso, pero creo que aún se debe mostrar 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 pueda incluir la zona horaria?
Si su zona horaria ha cambiado recientemente, cada vez que inicie sesión en la aplicación, se debe notificar que su zona horaria predeterminada se cambia a la zona horaria original.
Al crear un evento, digamos que el usuario selecciona la zona horaria desde el menú desplegable. No carga al usuario dando opciones de todas las zonas horarias del mundo. La primera opción del menú desplegable debe ser la zona horaria actual del dispositivo del usuario. después de esas zonas horarias de su historia de zonas horarias, luego UTC y 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 mientras programo 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 debería 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 necesite hacer ningún cálculo en su horario local, pero al mismo tiempo debe poder comunicarse con otros usuarios con fluidez en su zona horaria preferida.
El problema de almacenar marcas de tiempo es simple: almacenarlos en UTC.
En cuanto a mostrarlos, tendría sentido tomar la configuración de zona horaria del dispositivo y usar eso como la zona horaria actual. Dicho esto, debe haber un menú desplegable de zona horaria junto al cuadro de "entrada de tiempo", que por defecto es la zona horaria actual del dispositivo, para que el usuario pueda cambiarlo si es necesario.
La mayoría de sus usuarios probablemente no cambiarán demasiado 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 ser capaz de facilitar las cosas a quienes se mueven (porque normalmente comprenden mejor los husos horarios que los que no lo hacen).
De hecho, sería aún mejor guardar la zona horaria en la que se configuró el dispositivo cuando se ejecutó su aplicación por primera vez, y luego ver si alguna vez cambia. Si cambia, entonces el usuario probablemente sea un viajero y probablemente se beneficie al tener el menú desplegable de la 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 u 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.
- Use esa zona horaria como la zona horaria predeterminada. Siempre asuma esa zona horaria.
- Si el dispositivo cambia de zona horaria, agregue un menú desplegable para seleccionar la zona horaria en la que se encuentra el evento, de forma predeterminada en la zona horaria propia del dispositivo.
- Agregue una opción para mostrar / ocultar esta lista desplegable de zona horaria manualmente.
- Siempre almacene las marcas de tiempo en UTC.
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 mostramos la hora con la zona horaria .
En cuanto a almacenar las fechas, UTC es el camino a seguir. Convierte a UTC y pégalo en la base de datos. Al recuperar, simplemente convierta la hora a la zona horaria configurada para el usuario.
Tuve que resolver un caso de uso similar, donde las notificaciones personalizadas, como "Feliz año nuevo", podrían enviarse a todos los usuarios de la aplicación web. Dado que los usuarios están dispersos por todo el mundo, necesitábamos mostrar la notificación de acuerdo con la zona horaria. El almacenamiento de la marca de tiempo en UTC bien cumplió nuestro propósito, sin contratiempos.
En su caso de uso, si no está almacenando la zona horaria del usuario en alguna parte, nunca podrá devolver los resultados de búsqueda sin solicitar la entrada del usuario, a menos que empiece a usar algún tipo de detección de ubicación como lo hace gmaps, pero eso no es así. t confiable. Por lo tanto, deberá solicitar la zona horaria cada vez para asegurarse de que el usuario sepa qué está ingresando en el sitio web.
Si tiene información de zona horaria, toda la aplicación web se debe ejecutar con la configuración de la zona horaria. Por lo tanto, cuando el usuario busque las 9:00, buscará en 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. Solucionamos dichos casos mostrando siempre la zona horaria mientras mostramos las fechas.
¡Espero eso ayude! :)
Ok, tengo un enfoque diferente que otros:
En primer lugar, asumí pocas cosas antes de la mano.
La persona que está enumerando un evento tiene un teléfono inteligente (si es un navegador, no tengo que hacer estas suposiciones) con:
GPS
Capacidad de HTML5.
Capacidad de Javascript
¿Cómo debo guardar las marcas de tiempo en la base de datos?
Solución: Obviamente UTC , 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. Proporcione el (Largo, Lat) como argumentos para algunas de las api (Lat, Long) a TimeZone como la API de Yahoo (use Flag R para convertir la Latitude a la zona horaria) para obtener la zona horaria de los usuarios.
=> La zona horaria de los usuarios se determina sin la intervención del usuario (estoy usando esto porque no puedes simplemente asumir que el usuario conoce la zona horaria del lugar donde vive, conocía mi zona horaria solo después de algunos meses o algo en el lugar: P, ¡bastante tonto! )
Cada tabla de eventos tiene Timezone , Event y también puede tener CityName Luego, crea otra tabla de base de datos con clasificación basada en CityName s. Entonces aquí el usuario tendrá dos columnas
|---------------------------------------|
|_____NewYork________|______Sydney______|
| | |
|Event 1 | Event 2 |
|____________________|__________________|
Para UI
=> use Google Calendar API o algunas de las API de Calendar
Lecturas relacionadas:
Determine la zona horaria a partir de la latitud / longitud sin usar servicios web como Geonames.org
Sé que solo se trata de mostrar una idea de cómo resolver este problema. Pero vea qué tan precisa y liviana se vuelve en los usuarios cuando la Zona horaria se determina mediante el uso de las API del dispositivo
¡Espero eso ayude!
Para ese caso particular, almacenaría tanto la hora local como la hora UTC. UTC es algo importante y se usa para sincronización y conversión de tiempo 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 convertirla en tiempo de ejecución (esto es particularmente mejor en caso de que el usuario cambie la hora de la reunión). De cualquier manera, la razón principal es poder restaurar el tiempo de creación original para que el usuario pueda consultarlo.