Dois-je afficher le fuseau horaire si l'utilisateur n'est pas au même endroit que l'événement?
Dans un certain nombre d'applications que je conçois, le temps relatif à partir de maintenant est la référence de temps préférée. Par exemple. 'dernière mise à jour il y a 10 minutes'.
Quand il s'agit d'événements ou de diffusion depuis un endroit, cela devient moins simple. Ma préférence est de toujours gérer le temps de l'utilisateur, par exemple l'événement "commence dans 1 h" ou "samedi prochain à 17 h".
Ma question est de savoir dans quels cas il serait utile que les utilisateurs voient le fuseau horaire et comment le nommer au mieux pour correspondre au ton existant.
Outre les événements mentionnés dans les questions, je définis d'autres classes d'événements:
Événement local - événement, qui a lieu dans un endroit et nécessite une présence physique ( conférence ) ou en ligne dans le même fuseau horaire (communication d'équipe dans la même ville)
Événement mondial - événement qui implique un public mondial ( webinaire , vente aux enchères en ligne)
Il y a aussi Événement mixte , qui comprend en fait un événement local et mondial (ouverture des Jeux olympiques et sa traduction en ligne, annonce de la conférence et vente de billets) )
La règle générale pour l'utilisation des dates et des heures est la suivante:
- pour Événements locaux utiliser la date et l'heure de l'événement local, pas l'heure locale de l'utilisateur
date unique est cohérente parmi les utilisateurs internationaux, il n'y a pas de confusion lors du passage à d'autres fuseaux horaires. Le lieu de l'événement (par exemple Londres) crée une référence au fuseau horaire approprié, il est donc facile de calculer l'heure locale de l'utilisateur, bien qu'il ne soit pas utile. - pour Événements mondiaux utilisez les désignateurs de fuseau horaire et éventuellement l'heure relative de début ou d'expiration (en jours/heures/minutes)
. Il peut être converti en heure locale de l'utilisateur, mais cela nécessite un traitement supplémentaire côté serveur ou côté client (fonction native fonction toISOString () ou bibliothèque moment.js ) et n'est pas garanti à 100% (heure client incorrecte, javascript non fonctionnel, etc.). La référence de fuseau horaire permet une conversion facile en heure locale de l'utilisateur manuellement ou avec services en ligne .
Quelques exemples d'utilisation des règles:
Événement mixte: local (annonce de la conférence) et mondial (remboursement du billet en ligne)
Événements mondiaux - webinaires
Événement local - conférence
Événement mixte: local (conférence) et mondial (vente de billets) 
Événement mondial avec délai d'expiration - enchères en ligne
Vous pouvez donc voir que les indicateurs de fuseau horaire sont utilisés assez largement.
Sauf si vous affichez une heure avec des informations de localisation, je voudrais simplement l'afficher de manière cohérente dans le fuseau horaire local.
Exemple 1: Check-ins
Ceci est un exemple de l'endroit où vous [~ # ~] voudriez [~ # ~] voulez l'afficher dans le fuseau horaire spécifique.
Si vous affichez les enregistrements sur une carte. Vous souhaitez afficher les heures dans le fuseau horaire correspondant. Cependant, si vous essayez d'établir une chronologie autour de la visionneuse, vous fournirez les heures locales ou l'heure relative.
–– CHECK-IN ––––––––––––––––––––––––––––––– 1 day ago ––
Location: New York, NY
Time: 8:15am (EST) on Tuesday
–– CHECK-IN –––––––––––––––––––––––––– 32 minutes ago ––
Location: San Francisco, CA
Time: 9:28am (PST) Today
–– UPCOMING EVENT –––––––––––––––––––––––– in 2 hours ––
Location: Dallas, TX
Time: 2:00pm (CDT) Today
Exemple 2: Commentaires des utilisateurs
Ceci est un exemple de l'endroit où vous NE SERAIT PAS souhaitez afficher différents fuseaux horaires:
–– Comment by Joe ––––––––––––––––––
3:45pm
"This is great!"
–– Comment by David ––––––––––––––––
4:00pm
"I agree."
Dans ce cas, l'utilisation d'un fuseau horaire cohérent pour les valeurs d'affichage est importante pour maintenir une chronologie claire.
Informations supplémentaires
Les conventions de dénomination relèvent de la Interaction Design (IxD) vertical . Il y a quelques bons principes ici qui pourraient aider à donner un aperçu.
Chris Dixon vient de partager quelques réflexions sur les fuseaux horaires d'affichage récemment aussi.
La chose est très simple. Si votre actualité/événement a des utilisateurs mondiaux, vous devez afficher l'heure avec le fuseau horaire. Par exemple, si vous envoyez une demande de réunion à vos participants dans un autre pays où le fuseau horaire diffère de votre fuseau horaire, vous mentionnez toujours le fuseau horaire avec l'heure. EX. 10 mars 2014 14h30 PST OR 10 mars 2014 14h30 PST
OU si vous n'avez que des utilisateurs domestiques, il est bon d'afficher uniquement l'heure. EX. 10 mars 2014 14h30 OR 10 mars 2014 14h30
Mon employeur (une entreprise avec une présence mondiale) a ce problème. Ils citent exclusivement le temps de Pennsylvanie et ne font aucun effort pour le traduire en quelque chose de plus significatif ailleurs.
La plupart des gens qui doivent gérer des fuseaux horaires do savent ce qu'est GMT (ou peut-être UTC) et peuvent traduire GMT en heure locale. Le problème principal est d'identifier le décalage correct dans la multiplicité des abréviations de fuseau horaire disponibles, puis de calculer correctement l'heure locale. Il existe plusieurs sources d'erreur, qui peuvent toutes être aggravées. Qu'est-ce que CEST? ET inclut-il l'heure de l'heure d'été? Est-ce l'heure normale de l'Est EST ou l'heure d'été de l'Est?
Une solution raisonnable consiste à dire
Commence à 13 h HNE (18 h GMT)
et laisser les gens en Asie, ou en Europe centrale, ou en Grande-Bretagne à l'heure d'été, s'en sortir.
Une meilleure méthode, en particulier dans les navigateurs, consiste à utiliser Javascript [ou peut-être des utilitaires côté serveur ou Web] pour calculer le fuseau horaire local et à ajouter que, si les informations sont disponibles:
Commence à 13 h HNE (18 h GMT) (23 h 30 dans votre fuseau horaire)