time - reloj - Mostrar información de hora y zona horaria al usuario(qué, no cómo)

utc horario (13)

Como han mencionado otros, creo que si la aplicación es específica o local, puede omitir la zona horaria o hacer otras suposiciones.

Si es global, entonces desea almacenar los datos de manera consistente (siempre UTC), luego convierta para visualización. Además, querrá que el usuario especifique su zona horaria, y posiblemente también un formato de fecha y hora; ya sea dando varias opciones estáticas o dándoles toda la potencia para especificar una cadena de formato, si están lo suficientemente avanzados como para hacerlo.

Si no quiere dar opciones a sus usuarios, entonces un simple HH: MM TZ o HH: MM GMT +/- H parece adecuado? O simplemente podría mostrar la hora local en el servidor, luego en una nota al pie o preguntas frecuentes, decir "todas las veces son PST" o lo que sea.

Como usuario, preferiría la máxima capacidad de configuración, pero supongo que soy parcial, siendo un programador.

(Esta es una pregunta sobre la UI en lugar de la tecnología requerida para hacerlo)

¿Cuál es la forma más clara de mostrar un tiempo para los eventos que ocurren en diferentes zonas horarias a un usuario? ¿Su usuario "promedio" entiende UTC y zonas horarias?

Capturamos la hora local y el desplazamiento UTC y lo almacenamos en la base de datos (SQL 2008 DateTimeOffset) para eventos que ocurren en diferentes zonas horarias. Los usuarios también se encuentran en una variedad de zonas horarias.

Sugeriré un par de respuestas a continuación para que puedan ser evaluadas, pero apreciaría sugerencias alternativas.

EDIT: me gustaría evitar mostrar la hora en la zona horaria del usuario. Los usuarios en diferentes zonas horarias discutirán los mismos eventos y si son locales en diferentes zonas horarias, habrá confusión.

EDITAR: Quería hacer la pregunta genérica y con suerte útil para más personas, pero para un contexto específico, esta es una aplicación web para rastrear paquetes (piense en FedEx). Las parcelas cruzarán las zonas horarias. El servicio de atención al cliente está en el Reino Unido, pero el destinatario puede estar en otro lugar.

Creo que esto no puede ser respondido definitivamente sin una aplicación en particular. Por ejemplo, en una aplicación de intranet para todos los usuarios en la misma zona horaria, a menudo puede omitir la zona horaria por completo. Para una aplicación de mercado de valores, es posible que desee establecer el tiempo relativo a la zona horaria del mercado. Para una aplicación web social, es posible que desee establecer el tiempo relativo a la zona horaria del usuario. Creo que los principios generales que se aplicarían son:

Si existe la posibilidad de confusión, siempre debe especificar la zona horaria
Debe trabajar con sus usuarios para averiguar cómo quieren que se muestre la hora.

Después de haber sido mordido varias veces a lo largo de los años por aplicaciones "pequeñas" que repentinamente son nacionales (en los EE. UU., 5 o 6 husos horarios) o globales, siempre almaceno datos de fecha y hora en UTC si es posible.

El problema se convierte entonces en visualización, como lo han señalado otras publicaciones.

Si se muestra una fecha / hora, y se relaciona con la ubicación (y localidad) del usuario actual, muéstrela en la hora local del usuario.

Si se van a mostrar varias fechas / horas y se relacionan con diferentes lugares (posiblemente diferentes configuraciones regionales), he encontrado que los usuarios prefieren ver la hora que se muestra en la zona horaria de la ubicación, en formato de 12 horas.

Piense en cómo se imprimen los boletos de avión (al menos en los EE. UU.): Los horarios de salida y llegada se muestran en la zona horaria de la ciudad de salida y la ciudad de llegada. Los mejores itinerarios tienen un "tiempo total de viaje" o la duración que se muestra también.

Ok, entonces quieres mostrar los datos formateados de la configuración regional para el usuario: ¿Cómo se determina la configuración regional? Para aplicaciones web, aunque la configuración regional está presente en la mayoría de los encabezados HTTP, no siempre se puede confiar en que la configuración regional esté configurada correctamente en la máquina del usuario. Así que casi siempre terminamos pidiéndole al usuario que configure un perfil que incluya algunos datos de los cuales podemos determinar la configuración regional (código postal / postal, ciudad / estado / país, etc.) o ingresar algo que nos dé una idea de dónde el usuario reside realmente (para aplicaciones web o aplicaciones ''nativas'')

No tuve que implementar esto porque la geolocalización a través de la dirección IP se hizo ampliamente disponible, pero tampoco necesariamente es precisa.

Tenga en cuenta que cuando he trabajado en estas aplicaciones, mi configuración personal casi siempre termina en formato de 24 horas, UTC, ISO8601 solo para saber qué hora me está mostrando, independientemente de dónde se encuentre el usuario.

Esta es una situación terriblemente sensible al contexto. Me gustaría basarme en las sugerencias de postos y tvanfosson. No creo que se necesiten nombres de ciudades y países, excepto para ayudar a las personas a establecer su hora local y tal vez en un diálogo para establecer horarios que podrían ser para otros lugares cuando solo conocen la hora local deseada (gran desafío no abrumar / distraer usuarios con lo que es desordenado para ellos).

Si una ubicación está asociada con la hora, entonces la fecha y la hora en esa ubicación suelen ser apropiadas (por ejemplo, cuando se habla de cierres de mercados, eventos, llegadas y salidas de viajes, etc.). Estoy a favor de la idea de que un tool-tip está disponible para traducirlo a (1) gmt y (2) la hora local aparente del usuario que está viendo la interfaz. Las compensaciones también son útiles, y también la fecha en que están involucrados los cruces de medianoche.

También estoy de acuerdo en que la zona horaria debe ser explícita como una señal de que podría no ser la hora local. Además, incluso cuando se muestra una hora local sin zona horaria, creo que la información sobre herramientas sigue siendo importante. (Especialmente cuando alguien que viaja con una computadora portátil puede mantener la configuración de la zona horaria de su homebase).

Atención adicional al detalle: ocuparse de los cambios de horario para el horario de verano, el horario de verano, etc., y su diferencia entre ubicaciones (no todos los lugares tienen horario de verano, no todos los lugares hacen el cambio al mismo tiempo) y entre puntos de tiempo (en el futuro especialmente).

La estrategia debería ser que los tiempos en la IU, cuando el usuario los ingresa o los ingresa, estén en la zona horaria propia del usuario .

En la aplicación, por otro lado, es decir, en el código Ruby y en la base de datos, los tiempos siempre se guardan en la zona horaria UTC.

Su trabajo se convierte entonces para permitirle al usuario seleccionar una zona horaria, y luego convertir entre esta zona horaria y la zona horaria UTC según sea necesario.

Este artículo ilustra cómo hacerlo en un entorno de Rails.

Eso implica poder recuperar la zona horaria del usuario o haber almacenado esa zona horaria en una tabla de ''usuario''.

Lo mejor que puede hacer es almacenar toda la información de fecha / hora en UTC y luego mostrar las horas compensadas con el tiempo de los usuarios. .NET tiene todo tipo de soporte para esto; la mayoría de los otros entornos también lo hacen. alguien que ingrese datos en Londres a las 7 a.m. debe mostrar como 1 a.m. o 2 a.m. EDT. La mejor parte de UTC es que evita todas las cosas difíciles con los horarios de ahorro de luz natural o la falta de ellos cuando se encuentra en lugares que no lo tienen, por ejemplo. Corea, India vs las nuevas compensaciones para América del Norte.

Me gustan las 24 horas, como las 15:30 EDT, pero estoy seguro de que hay algunas que funcionan en el modo 12H. hacer de eso una opción segura.

Me gusta el desplazamiento GMT + (asumiendo que el desplazamiento "normalmente" será el huso horario del usuario). Como una pista adicional, proporcione una información sobre herramientas que enumere algunas ciudades en esa zona horaria (una por hemisferio) o un hipervínculo a alguna página que explique la zona horaria con más detalle.

Muestra la hora local y el desplazamiento de esta manera 15:18 GMT + 1

Muestrelo con la abreviación de Timezone

En lugar de

15:18 GMT+1

Mostrarlo como hora de Europa Central

15:18 CET

La gente está más acostumbrada a ver su propia zona horaria

Pruebe un gráfico de redacción antiguo, donde tenga relojes con la etiqueta "Nueva York", "Londres", "Tokio" y luego "Papua, Nueva Guinea" o donde se encuentre su visor en particular. Puede hacer que los relojes sean analógicos o digitales, o ambos.

Nadie se confundirá con esto, mientras que no creo que la mayoría de las personas realmente sepa lo que significa GMT + 7 (o lo que sea).

Lo que ha descrito es una situación en la que el espectador de la página está apoyando al cliente.

Por lo tanto, recomiendo que el diseño se centre en la perspectiva del cliente. Por lo tanto, el método de visualización predeterminado o principal debe ser la hora local del cliente. Si usa correo electrónico o mensajería instantánea, debe tener algún tipo de directorio de usuario como fuente. Si está hablando por teléfono, la identificación de llamadas puede ser la base de la conversión de tiempo.

Este es también un ejemplo de cómo el software es solo una parte, no toda la oferta de soporte. La pantalla debe permitir cambiar fácilmente a otras zonas horarias, y los representantes telefónicos siempre deben estar entrenados para preguntar en qué zona horaria se encuentran antes de proporcionar información basada en el tiempo.

También debe tener una opción para mostrar la hora local en el punto de llegada. Esto le permite conversar con el cliente de manera fluida y eficiente:

CU: "When will it arrive?" CS: "Based on your phone number, I am assuming you are in EST. The ETA is 8pm". CU: "I am traveling in Chicago right now. Can you tell me when I should check back?" (Phone rep taps a "CST" button on the screen, and the displays convert.) CS: "Sir, if the package does not arrive before 9:10pm, your local time, please call us."

Mencionas paquetes. La convención en logística es mostrar siempre las horas locales, que es lo que UPS y demás muestran en el historial de estado en sus datos de seguimiento y rastreo.

Si ese horario local no es la zona horaria de los usuarios actuales, entonces consideraría anotar la hora con la zona horaria, por ejemplo, 09:00 (Europa / Amsterdam) .

Tenga en cuenta que los nombres de lugares son mejores que las abreviaturas, que pueden ser ambiguas. Depende de usted decidir si es más útil decirle al usuario dónde está la hora o cuál es la diferencia con respecto a su zona horaria.

Una forma de evitar el problema es usar tiempos relativos, por ejemplo, hace 4 horas .

Mostrar siempre la hora en UTC

NB No estoy de acuerdo con esto. Acabo de agregarlo como una opción para votar.