Est-ce une bonne pratique d'inclure un fuseau horaire sur un horodatage?
Nous avons une application qui affiche des horodatages pour les choses qui se sont déjà produites - création, dernière modification, historique des activités.
Nous avons un client dont la source de ces événements (un utilisateur déclenchant une action) peut se trouver dans un fuseau horaire différent, et il nous a demandé d'ajouter des informations de fuseau horaire à l'écran. La majorité de nos autres clients travaillent dans un fuseau horaire.
Les heures sont toujours affichées en heure locale de l'appareil, il n'y aurait donc pas de changements logiques mais plutôt simplement l'ajout du fuseau horaire actuel des appareils ajouté à la fin de l'horodatage à l'écran.
Est-ce une bonne pratique de le faire ou existe-t-il une meilleure façon de transmettre cette information?
La spécification du fuseau horaire directement dans l'horodatage n'est ni une bonne ni une mauvaise pratique. La réponse à votre question a plus à voir avec votre expérience utilisateur que n'importe quelle documentation ou formatage d'horodatage.
Vous avez indiqué qu'un ou plusieurs de vos utilisateurs avaient demandé que le fuseau horaire soit ajouté à vos horodatages. Cela impliquerait que vos horodatages sont actuellement ambigus, ce que nous voulons éviter. Vous disposez de plusieurs options pour y remédier et améliorer l'expérience utilisateur.
- Ajoutez le fuseau horaire à l'horodatage (c'est clairement la solution la plus évidente à votre problème, qui est garantie de lever toute ambiguïté actuellement présente)
- Indiquez clairement quelque part (le "bon" quelque part étant la partie délicate) que tous les horodatages sont dans le fuseau horaire _______.
- Ferroutage sur # 1, autorisez cela comme une préférence utilisateur. Pour les utilisateurs de votre fuseau horaire principal, il peut être désactivé par défaut pour économiser un peu de place dans votre application, mais pour les personnes en dehors du fuseau horaire "normal", ils peuvent activer cette fonctionnalité.
- Utilisez des horodatages relatifs plutôt que des horodatages absolus car ils sont indépendants du fuseau horaire.
D'après l'expérience professionnelle, l'une des 4 options ci-dessus (y compris le mélange et l'appariement de plus d'une) pourrait être extrêmement bénéfique pour vos utilisateurs. Vous devrez finalement peser le temps de développement nécessaire pour effectuer le changement, mais la seule option que je dirais que vous ne devriez certainement pas suivre est de ne rien faire.
Cela dépend des autres horodatages que vous affichez sur votre site/application. Cependant, les horodatages sont presque toujours utilisés pour comparer des événements relativement dans une seule chronologie, donc dans presque toujours, il est préférable de s'en tenir à un seul fuseau horaire.
Donnez à l'utilisateur la possibilité de sélectionner son horodatage. Chargez toujours le fuseau horaire sélectionné par l'utilisateur et convertissez tous les horodatages en cet horodatage.
Pour les événements récents, pensez à utiliser un affichage "il y a longtemps". Pour un exemple, consultez cette horodatage des réponses. Il ne montre pas l'horodatage exact lorsque j'ai posté cette réponse; il montre combien de minutes/heures je l'ai fait, et vous pouvez traiter ces informations rapidement quel que soit le fuseau horaire dans lequel vous vous trouvez.
Si vous affichez des marqueurs "il y a longtemps", vous pouvez également obtenir l'horodatage exact.
Pour les filtres, vous pouvez également ajouter des filtres temporels relatifs. Voir ceci pour un exemple:
Tout le monde a déjà répondu à votre question, donc je ne vais pas y aller :)
Mon commentaire est plus une suggestion.
Veuillez éviter les horodatages éthérés comme: "Today", "Yesterday", "10 minutes ago", "A week ago". Nous ne voulons pas penser combien de temps était "il y a 10 minutes" à partir du moment où nous lisons le contenu; encore moins "Il y a une semaine".
Je suggère de toujours utiliser la date et l'heure. Il suffit de regarder les horodatages de SE: parfait.
La date devra être formatée en fonction de la région/du pays où elle est affichée:
- Aux États-Unis, nous utilisons
Month/Day/Year. - En Amérique latine, ils utilisent
Day/Month/Year. - Aux Philippines, ils utilisent à la fois
Month/Day/YearetDay/Month/Year. - En Chine, ils utilisent
Year/Month/Day(qui pour moi a le plus de sens).
Voir toutes les régions ici:
Format de date par pays
Je peux penser à 2 autres options
1.Pour afficher l'heure au format international (si ce n'est pas le cas actuellement)
hh: mm: ss
De plus, nous pouvons ajouter le fuseau horaire comme
IST 17:09:27
Cela devrait éliminer toute confusion pour l'utilisateur et ne pas prendre trop de place.
Je ne pense pas qu'il serait logique d'ajouter car tout le monde voit l'heure locale de son appareil. Au lieu de cela, vous pouvez indiquer depuis combien de temps l'action a été effectuée pour une meilleure compréhension. Un algorithme convivial peut être élaboré. Par exemple, si moins d'une minute, afficher en secondes, si moins d'une heure afficher en minutes, etc.
Les événements se produisent dans un "point dans le temps", exprimé en chiffres.
Par exemple, un événement qui se produit à 16 heures à Londres sera considéré comme se déroulant à 13 heures à Buenos Aires. Deux temps différents (nombres) qui dénotent le même point dans le temps.
Maintenant, la façon dont vous le décrivez dépend de l'application particulière.
Par exemple, si vous voulez voir la distribution des événements le long des heures de la journée, comme à quelle heure de la journée les gens prennent le petit-déjeuner n'importe où, alors vous feriez mieux avec l'heure locale de chaque événement.
Dans ce cas, vous constaterez que les habitants de Buenos Aires prennent leur petit-déjeuner vers 8 h 00 GMT-3.
Les habitants de Londres déjeunaient peut-être à 8h GMT, c'est-à-dire à la même heure locale mais trois heures plus tôt.
Même temps, différents moments.
Au contraire, si vous traitez à quelle heure une audience mondiale frappe un serveur, alors tous les horodatages seraient mieux liés au fuseau horaire de l'emplacement du serveur.