Comment puis-je gérer les fuseaux horaires dans mon application Web?

Je cherche une meilleure compréhension de la user story suivante:

John travaille à Sidney. À 9 heures du matin, il enregistre un événement dans une application Web qui s’exécute sur un serveur à Zurich. Le lendemain, il se rend à New York pour une réunion d’urgence au cours de laquelle l’événement doit être discuté. Pendant la réunion, il recherche l’événement par date et heure.

À mon avis, il y a au moins deux problèmes ici:

  1. Comment enregistrer les horodatages dans la firebase database?
  2. Comment devrais-je les présenter dans l’interface utilisateur?

Lorsque John recherche l’événement, il saura que cela s’est produit à 9h00, mais que devrait-il entrer dans le navigateur Web? Il ne trouvera rien quand il entre simplement “9:00” comme horodatage, car cela pourrait être l’heure de Zurich ou de New York (puisque l’événement n’a pas été trouvé, l’application n’a aucun moyen de savoir que cela s’est produit à Sidney, alors il ne peut pas sélectionner automatiquement le bon fuseau horaire).

Quel est le bon moyen de demander à l’utilisateur un horodatage pouvant inclure le fuseau horaire?

Le deuxième problème est de savoir comment afficher les résultats. Si des équipes du monde entier ont besoin de discuter de l’événement (et de trouver des événements connexes, pensez à une attaque de pirate ciblant plusieurs sites du monde entier).

Quel est un bon exemple pour l’affichage des horodatages qui pourraient avoir été créés dans un fuseau horaire différent?

Note: Veuillez vous concentrer sur la facilité d’utilisation de l’exigence. Je peux comprendre la cartographie de la firebase database moi-même. Actuellement, je ne suis pas sûr du stream de travail. Il devrait demander / présenter les informations nécessaires de manière non intrusive / intuitive. Si vous le pouvez, donnez un lien vers une application Web existante qui résout déjà ce problème.

Le problème du stockage des horodatages est simple: stockez-les en UTC.

Comme pour les afficher, il serait judicieux de prendre le réglage du fuseau horaire de l’appareil et de l’utiliser comme fuseau horaire actuel. Cela dit, il devrait y avoir un menu déroulant de fuseau horaire à côté de la case “time input”, qui utilise par défaut le fuseau horaire actuel de l’appareil, afin que l’utilisateur puisse le modifier si nécessaire.

La majorité de vos utilisateurs ne changera probablement pas beaucoup de fuseau horaire, ou pas du tout. La plupart du temps, la situation que vous avez décrite est rare. En implémentant une liste déroulante avec une valeur par défaut appropriée, vous devriez être en mesure de rendre les choses assez faciles pour ceux qui se déplacent (car ils ont généralement une meilleure compréhension des fuseaux horaires qu’un non-voyageur).

En fait, il serait préférable de sauvegarder le fuseau horaire sur lequel l’appareil a été configuré lors de la première exécution de l’application, puis de voir s’il a été modifié. Si cela change, l’utilisateur est probablement un voyageur et bénéficierait probablement de la liste déroulante des fuseaux horaires. Sinon, il suffit de ne pas afficher la liste déroulante et la valeur par défaut du fuseau horaire du périphérique (car l’utilisateur n’a pas besoin de les connaître). Dans les deux cas, définissez dans l’application un paramètre permettant à l’utilisateur d’afficher / masquer manuellement le menu déroulant du fuseau horaire.


Pour résumer ce qui précède:

  • Lors de la première exécution, enregistrez le fuseau horaire sur lequel le périphérique est défini.
  • Utilisez ce fuseau horaire comme fuseau horaire par défaut. Assumez toujours ce fuseau horaire.
  • Si l’appareil change de fuseau horaire, ajoutez une liste déroulante pour sélectionner le fuseau horaire dans lequel se trouve l’événement, par défaut pour le fuseau horaire du périphérique.
  • Ajoutez une option pour afficher / masquer manuellement cette liste déroulante.
  • Toujours stocker les horodatages en UTC.

Dans nos applications, nous stockons généralement le fuseau horaire de l’utilisateur lors de notre première inscription, comme cela est souvent le cas sur les sites du forum, et affichons toujours l’heure avec le fuseau horaire .

En ce qui concerne le stockage des dates, l’UTC est la voie à suivre. Convertissez en UTC et collez-le dans la firebase database. Lors de la récupération, convertissez simplement l’heure en fuseau horaire défini pour l’utilisateur.

J’ai dû résoudre un cas d’utilisation similaire, où des notifications personnalisées, telles que “Happy New Year”, pouvaient être envoyées à tous les utilisateurs de l’application Web. Comme les utilisateurs sont répartis dans le monde entier, nous avons dû afficher la notification en fonction du fuseau horaire. Stocker l’horodatage en UTC a bien servi notre objective, sans heurts.

Dans votre cas d’utilisation, si vous ne stockez pas le fuseau horaire de l’utilisateur, vous ne pourrez jamais retourner avec précision vos résultats de recherche sans demander la saisie de l’utilisateur, sauf si vous utilisez une détection d’emplacement telle que gmaps. t fiable. Vous devrez donc demander un fuseau horaire à chaque fois pour vous assurer que l’utilisateur sait ce qu’il entre sur le site.

Si vous disposez d’informations de fuseau horaire, l’application Web entière doit être exécutée avec le paramètre de fuseau horaire. Par conséquent, lorsque l’utilisateur effectue une recherche à 9 heures, il recherche le fuseau horaire de Sydney. Par contre, s’il crée un événement assis à New York, il créera un événement avec le fuseau horaire de Sydney. Nous résolvons ces cas en affichant toujours le fuseau horaire tout en affichant les dates.

J’espère que cela aide! 🙂

  1. UTC. Rester simple.

  2. Utilisez le fuseau horaire le plus pertinent pour l’utilisateur.

    Si vous savez que l’utilisateur se rendra à Sydney ou se rendra à Sydney pour l’événement, il pensera à ce fuseau horaire lorsqu’il organisera le transport jusqu’à l’événement. Le fait qu’ils se trouvent actuellement à New York n’est guère pertinent. Et bien sûr, si votre application affiche des dates dans une variété de fuseaux horaires, elle devrait toujours afficher le fuseau horaire à côté de la date, par exemple 09:00 EST .

    Si votre interface n’est pas trop encombrée, vous pouvez afficher les dates dans le fuseau horaire de l’événement et dans le fuseau horaire local, par exemple 2012-06-13 09:00 EST (2012-06-12 19:00 HAE) .

    Je dirais que la recherche est un problème similaire, avec une mise en garde: nous pouvons tolérer les faux positifs (obtenir un résultat auquel nous ne nous attendions pas), mais nous ne supportons pas les faux négatifs (pas de résultat attendu).

    Encore une fois, je me concentrerais sur la recherche du fuseau horaire le plus pertinent pour l’utilisateur (par exemple, le fuseau horaire de l’événement) et donnerais la priorité à ces résultats dans les résultats de recherche. heure locale). Si vous faites cela, vous devez afficher la date de l’événement dans le fuseau horaire correspondant, surtout si vous mettez en surbrillance le texte correspondant.

Ici, je donne des suggestions pour une meilleure facilité d’utilisation sans trop me soucier de la faisabilité de la mise en œuvre.
1. Pour le premier numéro de stockage des événements dans la firebase database, tout le monde accepterait de le stocker en UTC

2. Pour offrir la meilleure expérience utilisateur, enregistrez l’historique du fuseau horaire de l’utilisateur. Si vous pouviez économiser l’horodatage du changement de fuseau horaire, encore mieux. Cela nous permettra de donner la liberté à l’utilisateur d’interroger sans spécifier de fuseau horaire explicitement à chaque fois.

Donc, avec ces fonctionnalités, voyons comment la requête de recherche de “9.00” par John sera traitée:
Avec les fonctionnalités mentionnées ci-dessus, je sais maintenant que John a été dans 2 fuseaux horaires jusqu’à la date (ou obtenir la liste des fuseaux horaires pour la période mentionnée). Donc, je vais couvrir 9 heures du fuseau horaire de Sydney à UTC, lancer une requête. Convertissez également 9.00 du fuseau horaire NewYork en UTC, lancez une requête. En conséquence, je montrerai 2 lignes à John pour montrer ce qu’il a fait à 9h00 à Sydney et à 9h00 à New York. New York Line sera vide dans ce cas, mais je pense que devrait toujours être montré à l’utilisateur, juste pour l’informer que nous avons également recherché ce fuseau horaire.

3.Quel est le bon moyen de demander à l’utilisateur un horodatage pouvant inclure le fuseau horaire?

Si son fuseau horaire a été modifié récemment, chaque fois qu’il se connecte à l’application, une notification doit être envoyée, votre fuseau horaire par défaut est remplacé par le fuseau horaire natif.
Lors de la création d’un événement, disons que l’utilisateur sélectionne le fuseau horaire dans le menu déroulant. Ne pas alourdir l’utilisateur en donnant des options de tous les fuseaux horaires du monde. La première option du menu déroulant doit être le fuseau horaire actuel de l’utilisateur. après ces fuseaux horaires de son historique de fuseaux horaires, puis UTC, puis les fuseaux horaires restants qu’il n’a jamais utilisés jusqu’à la date.

4.Comment afficher les résultats, si les équipes du monde entier ont besoin de discuter de l’événement:

Je voudrais diviser ce cas d’utilisation entre le nombre d’équipes 2 ou plus de 2.
Pour seulement deux équipes, je préférerais que chaque équipe voit l’horodatage dans son fuseau horaire local et dans le fuseau horaire d’une autre équipe. (Personnellement, je préfère parler dans le fuseau horaire de la personne à l’autre bout pour sa commodité lors de la planification d’une réunion). Pour plus de 2 équipes, il est préférable de prendre en compte un fuseau horaire plus commun, par exemple l’UTC. Donc, dans ce cas, chaque utilisateur doit voir l’horodatage dans 2 fuseaux horaires, en UTC et dans son fuseau horaire par défaut.

Ces suggestions sont données avec l’intention que l’utilisateur n’a pas à faire de calcul dans son heure locale, mais en même temps il devrait pouvoir communiquer avec les autres utilisateurs couramment dans leur fuseau horaire préféré.

Ok, j’ai une approche différente des autres:

Tout d’abord, j’ai pris peu de choses avant la main.

La personne qui énumère un événement a un smartphone (si c’est un navigateur, je n’ai pas à faire ces hypothèses) avec:

  1. GPS

  2. Capacité HTML5

  3. Fonction Javascript

Comment enregistrer les horodatages dans la firebase database?

Solution: Evidemment UTC , j’ai superposé la procédure ci-dessous:

Étape 1. Utiliser la géolocalisation de l’utilisateur à l’aide de l’API de géolocalisation

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; } 

Étape 2. Donnez le (Long, Lat) comme argument à certains api (Lat, Long) à TimeZone comme l’ API Yahoo (utilisez Flag R pour convertir la latitude en fuseau horaire) afin d’obtenir le fuseau horaire des utilisateurs.

=> Le fuseau horaire des utilisateurs est déterminé sans saisie de l’utilisateur (je l’utilise car vous ne pouvez pas simplement supposer que l’utilisateur connaît le fuseau horaire du lieu où il vit, je connaissais mon fuseau horaire après quelques mois ou quelque chose à la place: P, bête! )

Chaque table Event possède un Timezone , Event & so peut également avoir CityName ensuite une autre table de firebase database avec une classification basée sur CityName s. Donc, ici, l’utilisateur aura deux colonnes

 |---------------------------------------| |_____NewYork________|______Sydney______| | | | |Event 1 | Event 2 | |____________________|__________________| 

Pour l’interface utilisateur

=> utiliser l’API Google Agenda ou certaines API du calendrier

Lectures connexes:

  1. Déterminer le fuseau horaire à partir de la latitude / longitude sans utiliser les services Web comme Geonames.org

  2. Recherche dans le fuseau horaire de la longitude de latitude

Je sais que c’est juste pour montrer comment résoudre ce problème. Mais voyez à quel point il devient précis et léger sur les utilisateurs lorsque le fuseau horaire est déterminé à l’aide des API de périphérique

J’espère que cela aide!

Pour ce cas particulier, je stockerais à la fois l’heure locale et l’heure UTC. UTC est un peu important et utilisé pour la synchronisation et la conversion du temps en fuseau horaire actuel. Local est utilisé pour les recherches et pour des informations supplémentaires, telles que:

Vous avez une réunion:

 12:00 Monday (UTC) 9:00 Monday (Sydney, creation local time) 11:00 Monday (Zurich, local time) 

ou quelque chose comme ça. L’autre moyen consiste à stocker le fuseau horaire de création et à le convertir à l’exécution (cela est particulièrement préférable dans le cas où l’utilisateur changera l’heure de la réunion). Dans tous les cas, la principale raison est de pouvoir restaurer le temps de création d’origine afin que l’utilisateur puisse s’y référer.

  1. Comment enregistrer les horodatages dans la firebase database?

Lors de la création d’un événement, je stockais l’heure UTC et le fuseau horaire local (ou fuseau horaire de creation time zone ). J’utiliserais ce que j’ai stocké pour convertir l’heure UTC en heure locale (aka creation time ) et la stocker avec l’heure UTC et le fuseau horaire de creation time zone .

REMARQUE: je peux stocker l’heure locale dès le départ, mais lorsque l’utilisateur effectue une recherche pour un événement, j’espère qu’une conversion à l’heure locale existe. J’espère également que le serveur peut détecter le fuseau horaire dans lequel se trouve le client.

  1. Comment devrais-je les présenter dans l’interface utilisateur?

Lorsqu’un utilisateur recherche “9:00”, je rechercherais les événements qui incluent “9:00” dans l’heure de creation time ou de creation time UTC OU l’ creation time locale. Pour les résultats, j’afficherais une table de résultats au creation time (ceci est destiné à afficher les horodatages qui peuvent avoir été créés dans un fuseau horaire différent, car nous supposons que l’utilisateur recherche l’heure à laquelle il a créé .), et affichez un second tableau de résultats ci-dessous avec les résultats associés, éventuellement avec l’en-tête “Pas ce que vous cherchez? Voir les résultats associés” (ceux-ci incluent les résultats UTC et locaux).

Globalement, je pouvais afficher l’heure UTC, l’heure locale, l’ creation time et le creation time zone (c’est-à-dire l’heure locale et le fuseau horaire de l’événement), sortingés par heure UTC. , au cas où deux événements différents seraient programmés à 9h00 dans deux fuseaux horaires différents.