Quel fuseau horaire utiliser pour visualiser les données?
Nous avons une application web avec des données de séries temporelles scientifiques que nous montrons dans des graphiques et autres. Les données sont des mesures de nombreux capteurs différents, souvent prises toutes les minutes environ.
Le fuseau horaire dans lequel l'utilisateur se trouve actuellement peut ne pas être le même que le fuseau horaire d'où proviennent les données, à la fois parce que l'utilisateur peut être ailleurs géographiquement et parce que nous pouvons regarder les données d'hiver en été (heure d'été).
Quel fuseau horaire est-il préférable d'utiliser lors de la visualisation des données?
Le fuseau horaire local du capteur lorsque les données ont été enregistrées - cela a plus de sens lorsque vous regardez les anciennes données, car vous voyez alors des températures élevées pendant la journée, etc.
Le fuseau horaire local de l'utilisateur, tel qu'il était au moment où les données ont été enregistrées (utilisez l'heure d'hiver locale pour les données enregistrées en hiver) - la plupart des gens s'attendent à ce que les heures dans une application Web reflètent leur propre heure locale, mais cela signifie que les données vous voyez dépend de l'endroit où vous vous trouvez en ce moment.
Il suffit de toujours montrer UTC et de laisser l'utilisateur s'en occuper, mais la plupart du temps, l'utilisateur sera en fait dans le même fuseau horaire que le capteur, généralement pas UTC.
Autre chose.
Il n'y a probablement pas de meilleure réponse, y a-t-il une pratique courante?
Vous faites de votre mieux pour afficher les heures dans les fuseaux horaires auxquels les utilisateurs s'attendent à voir les données.
Pour la plupart des ensembles de données scientifiques, le spectateur essaie de comprendre les modèles à partir des données d'une région particulière. Dans ce cas, le fuseau horaire du téléspectateur n'est pas pertinent. Affichez les données en utilisant le fuseau horaire de la région où elles sont capturées. Pour utiliser un exemple extrême, vous montrez les précipitations et la température au fil du temps en Australie. Cela n'aura de sens que d'étiqueter décembre comme été même si le spectateur vient d'Amérique du Nord.
Pour les ensembles de données liés à l'ordinateur/serveur où les points horaires exacts sont importants, si le téléspectateur comprend ce que représente l'UTC, l'UTC est probablement une valeur sûre pour normaliser l'heure, car vous évitez les problèmes dus aux fuseaux horaires et à l'heure d'été et tout ce qui est bien.
Le traçage des données avec des fuseaux horaires non locaux a été un problème dans l'un des projets sur lesquels j'ai travaillé.
Peu de temps après le lancement du produit, nous avons remarqué un problème lorsque nous avons vu des données sur les bâtiments à New York à partir d'ordinateurs en Californie qui n'avaient jamais fait surface dans nos tests automatisés ou nos efforts manuels d'AQ: tous nos graphiques pour les bâtiments de New York affichaient des heures sur des points de données ou Les graduations de l'axe X correspondent à l'heure normale du Pacifique (PST) plutôt qu'à l'heure normale de l'Est de New York (EST).
Bien que l'on puisse dire qu'il est agréable de voir les données traduites dans votre propre fuseau horaire où que vous soyez, il n'est pas commode de penser à des opérations de construction à distance à partir d'un fuseau horaire différent du sien du bâtiment. Notre problème était spécifique, c'était une visualisation critique pour la mission. Nous avons dû le réparer.
La réponse que vous cherchez est donc "cela dépend". Les critères doivent être choisis selon vos besoins d'utilisateur. Je vous conseille d'analyser le type d'informations dans votre graphique, si elles étaient essentielles à la mission comme la nôtre, vous devez respecter une norme. Si ce n'est pas le cas, soyez aussi flexible que possible car cela ne fait jamais de mal de donner à l'utilisateur une option pour une autre vue.
En ce qui concerne les plugins javascript qui peuvent vous aider, je vous recommande de rechercher http://momentjs.com/timezone/
Possibilité: choisissez un fuseau horaire par défaut (par exemple, UTC), puis demandez à l'utilisateur de choisir un fuseau horaire différent à utiliser. (Ou, demandez d'abord à l'utilisateur le fuseau horaire, ou choisissez ce fuseau horaire de préférence dans ses paramètres utilisateur qu'il peut modifier.)
Cela dépend vraiment de l'analyse type à effectuer avec les données. Si l'analyse est soit locale (par exemple, les tendances des mesures d'un capteur au fil du temps), soit indépendante du temps (par exemple, comparaison des valeurs moyennes de différents capteurs), vous devez vous en tenir à l'heure locale associée à l'événement d'enregistrement, ce qui est le moins déroutant pour le utilisateur. Comme vous l'avez dit vous-même, les tendances naturelles comme le cycle de température quotidien auront l'air, bien, naturelles.
Cependant, une fois que vous commencez à considérer les données sur une fenêtre de temps pour plusieurs fuseaux horaires en même temps, je pense que vous devriez opter pour UTC et laisser l'utilisateur effectuer des conversions de temps. L'inconvénient d'être moins naturel par rapport à l'heure locale sera compensé par les avantages suivants:
Bien que la gymnastique mentale avec les fuseaux horaires soit difficile, la règle elle-même est simple . Tout ce que vous avez à dire aux utilisateurs est "tous les horodatages sont en UTC". Qu'un emplacement particulier soit soumis à l'heure d'été (alias heure d'été) ou se déplace d'un fuseau horaire à un autre ne vous concerne pas. Et les utilisateurs locaux connaissent ces détails mieux que vous.
C'est le seul moyen que je connaisse pour rendre les choses cohérentes . Si vous respectez les heures locales, vous avez la garantie qu'un utilisateur demande: "le tableau récapitulatif indique qu'il y a eu 24 mesures ce jour-là, mais le nuage de points n'en montre que 23, qu'est-ce qui ne va pas avec votre application?" Et peu importe la précision avec laquelle vous expliquez que le résumé est calculé sur plusieurs fuseaux horaires et que sa notion de "jour" est différente du nuage de points, ces questions continueront d'apparaître.
J'ai déjà été impliqué dans un projet qui a choisi le timing UTC partout de manière précise pour des raisons de cohérence. Étant donné que chaque "mesure" dans notre cas était une personne recevant une dose de rayonnement, les statistiques devaient être cohérentes quoi qu'il arrive. Un point de données inactif de 23:45 non inclus dans le rapport, car il a été reporté au lendemain dans un fuseau horaire local, pourrait être considéré comme une tentative de modifier les résultats de l'audit, avec des conséquences désastreuses pour le malheureux utilisateur.