web-dev-qa-db-fra.com

Comment gérer les fuseaux horaires dans ma webapp?

Je recherche 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 devrait être discuté. Lors de la réunion, il recherche l'événement par date et heure.

Selon moi, il y a au moins deux problèmes ici:

  1. Comment dois-je enregistrer les horodatages dans la base de données
  2. Comment dois-je les présenter dans l'interface utilisateur

Lorsque John cherchera l'événement, il saura que cela s'est produit à 9h00, mais que doit-il saisir dans le navigateur Web? Il ne trouvera rien quand il entrera juste "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 passé à Sidney, donc il ne peut pas sélectionner automatiquement le bon fuseau horaire).

Quelle est la bonne façon 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 cracker qui cible plusieurs sites à travers le monde à la fois).

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

Remarque: veuillez vous concentrer sur la convivialité de l'exigence. Je peux comprendre moi-même le mappage de la base de données. Actuellement, je ne suis pas sûr du déroulement du travail. Il doit 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.

web-applicationstimezoneusability
89
Aaron Digulla

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

Quant à les afficher, il serait judicieux de prendre le paramètre de fuseau horaire de l'appareil et de l'utiliser comme fuseau horaire actuel. Cela dit, il devrait y avoir une liste déroulante de fuseau horaire à côté de la case "entrée de temps", qui correspond par défaut au fuseau horaire actuel de l'appareil, afin que l'utilisateur puisse le modifier si nécessaire.

La majorité de vos utilisateurs ne changeront probablement pas beaucoup, ou pas du tout. Pour la plupart, 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 encore mieux d'enregistrer le fuseau horaire sur lequel l'appareil a été défini lors de la première exécution de votre application, puis de voir s'il change jamais. Si cela change, l'utilisateur est probablement un voyageur et bénéficierait probablement de la liste déroulante du fuseau horaire. Sinon, n'affichez pas la liste déroulante et le fuseau horaire de l'appareil par défaut (car l'utilisateur n'a pas besoin de les connaître). Dans les deux cas, un paramètre dans l'application permet à l'utilisateur d'afficher/masquer manuellement la liste déroulante du fuseau horaire.

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

  • Lors de la première exécution, enregistrez le fuseau horaire sur lequel l'appareil est défini.
  • Utilisez ce fuseau horaire comme fuseau horaire par défaut. Supposez toujours ce fuseau horaire.
  • Si l'appareil change de fuseau horaire, ajoutez une liste déroulante pour sélectionner le fuseau horaire dans lequel l'événement se trouve, par défaut sur le fuseau horaire de l'appareil.
  • Ajoutez une option pour afficher/masquer cette liste déroulante de fuseau horaire manuellement.
  • Stockez toujours les horodatages en UTC.
84
Niet the Dark Absol

Dans nos applications, nous stockons généralement le fuseau horaire de l'utilisateur lors de notre première inscription, comme on le voit souvent sur les sites de forum, et toujours afficher l'heure avec le fuseau horaire.

Quant au stockage des dates, l'UTC est la voie à suivre. Convertissez en UTC et collez-le dans la base de données. 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, comme "Happy New Year", pouvaient être envoyées à tous les utilisateurs de l'application Web. Étant donné que les utilisateurs sont répartis dans le monde entier, nous devions afficher la notification en fonction du fuseau horaire. Le stockage de l'horodatage en UTC a bien rempli notre objectif, sans hoquet.

Dans votre cas d'utilisation, si vous ne stockez pas le fuseau horaire de l'utilisateur quelque part, vous ne pourrez jamais retourner avec précision vos résultats de recherche sans demander la saisie de l'utilisateur, sauf si vous commencez à utiliser une sorte de détection d'emplacement comme le font les gmaps, mais ce n'est pas le cas. t fiable. Vous devrez donc demander le fuseau horaire à chaque fois pour vous assurer que l'utilisateur sait ce qu'il entre dans le site Web.

Si vous disposez d'informations sur le 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 recherche 9h00, il effectue une recherche avec le fuseau horaire de Sydney. D'un autre côté, s'il crée un événement en étant assis à New York, il créera un événement avec le fuseau horaire de Sydney. Nous résolvons de tels cas en affichant toujours le fuseau horaire tout en affichant les dates.

J'espère que ça aide! :)

19
Varun Achar

  1. UTC. Rester simple.

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

    Si vous savez que l'utilisateur va être ou voyager à Sydney pour l'événement, alors il sera pensant dans ce fuseau horaire lors de l'organisation du transport vers l'événement. Le fait qu'ils soient actuellement à New York est largement hors de propos. Et bien sûr, si votre application affiche des dates dans différents fuseaux horaires, elle doit toujours afficher le fuseau horaire à côté de la date, par exemple 9:00 EST.

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

    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 que nous n'attendions pas), mais nous ne pouvons pas supporter les faux négatifs (ne pas obtenir le résultat que nous attendions).

    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 la recherche, mais vous pouvez également renvoyer des événements qui correspondent dans d'autres fuseaux horaires pertinents pour l'utilisateur (par exemple heure locale). Si vous procédez ainsi, vous devez afficher la date de l'événement dans le fuseau horaire correspondant, surtout si vous mettez en surbrillance le texte correspondant.

10
Richard Poole

Ici, je donne des suggestions pour une meilleure convivialité sans se soucier beaucoup de la faisabilité de la mise en œuvre.
1. Pour le premier numéro de stockage d'événements dans db, tout le monde serait d'accord pour le stocker en UTC

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

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

3.Quelle est la bonne façon de demander à l'utilisateur un horodatage pouvant inclure le fuseau horaire?

Si son fuseau horaire a été récemment modifié, chaque fois qu'il se connecte à l'application, une notification doit être envoyée, votre fuseau horaire par défaut est changé en fuseau horaire natif.
Lors de la création d'un événement, disons que l'utilisateur sélectionne le fuseau horaire dans la liste déroulante. Ne charge pas l'utilisateur en donnant des options de tous les fuseaux horaires du monde. après cela les fuseaux horaires de son histoire de fuseaux horaires, puis UTC et ensuite les fuseaux horaires restants qu'il n'a jamais utilisés jusqu'à ce jour.

4.Comment afficher les résultats, si des équipes du monde entier doivent discuter de l'événement:

Je voudrais diviser ce cas d'utilisation entre le nombre d'équipes 2 ou plus de 2.
Pour seulement 2 équipes, je préférerais que chaque équipe voit l'horodatage dans son fuseau horaire local et le fuseau horaire de l'autre équipe. (Personnellement, je préfère parler dans le fuseau horaire de la personne à l'autre extrémité pour sa commodité lors de la planification d'une réunion). Pour plus de 2 équipes, il vaut mieux considérer un fuseau horaire plus commun, c'est-à-dire UTC. Ainsi, dans ce cas, chaque utilisateur devrait 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'ait pas besoin de 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é.

7
Pranalee

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

Tout d'abord, j'ai supposé peu de choses à l'avance.

La personne qui annonce un événement a un smartphone (si c'est un navigateur, je n'ai pas à faire ces suppositions) avec:

  1. GPS

  2. Capacité HTML5.

  3. Capacité Javascript

Comment dois-je enregistrer les horodatages dans la base de données?

Solution: Évidemment [~ # ~] utc [~ # ~] , J'ai superposé la procédure ci-dessous:

Étape 1. Utilisez 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 arguments à certains des (Lat, Long) aux API de TimeZone comme le Yahoo API (utilisez le drapeau R pour convertir la latitude en fuseau horaire) pour obtenir le fuseau horaire des utilisateurs.

=> Le fuseau horaire des utilisateurs est déterminé sans intervention de l'utilisateur (J'utilise ceci parce que vous ne pouvez pas simplement supposer que l'utilisateur connaît le fuseau horaire de l'endroit où il vit, je ne connaissait mon fuseau horaire qu'après quelques mois ou quelque chose à l'endroit: P, assez stupide!)

Chaque table d'événements a Timezone, Event et peut donc également avoir CityName Ensuite, créez une autre table de base de données avec une classification basée sur CityNames. Donc, ici, l'utilisateur aura deux colonnes

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

Pour l'interface utilisateur

=> utiliser l'API Google Agenda ou certaines des API Google Agenda

Lectures associées:

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

  2. recherche de fuseau horaire à partir de la longitude de latitude

Je sais que c'est juste pour montrer une idée de la façon de résoudre ce problème. Mais voyez à quel point il devient précis et léger pour les utilisateurs lorsque le fuseau horaire est déterminé en utilisant les API de périphérique

J'espère que ça aide!

4
uday
  1. Comment dois-je enregistrer les horodatages dans la base de données

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

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

  1. Comment dois-je les présenter dans l'interface utilisateur

Lorsqu'un utilisateur recherche "9:00", je recherche des événements qui incluent "9:00" dans UTC OU creation time OU heure locale. Pour les résultats, je voudrais afficher un tableau de résultats dans 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éé un événement où qu'il soit.), Et afficher un deuxième tableau de résultats ci-dessous avec les résultats associés, peut-être avec l'en-tête "Vous n'êtes pas à la recherche? Voir les résultats associés" (il s'agit notamment des résultats UTC restants et de l'heure locale).

Dans l'ensemble, j'afficherais l'heure UTC, l'heure locale, le creation time, et le creation time zone (c'est-à-dire l'heure locale et le fuseau horaire de l'événement où il a été créé) triés par heure UTC, afin que vous puissiez voir quel événement vient en premier, au cas où deux événements différents étaient programmés à 9h00 dans deux fuseaux horaires différents.

2
user5398447

Pour ce cas particulier, je stockerais les deux heure locale et UTC. L'UTC est quelque peu majeur et utilisé pour la synchronisation et la conversion de l'heure en fuseau horaire actuel. Local est utilisé pour les recherches et pour des informations supplémentaires, comme:

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 à effectuer une conversion au moment de l'exécution (cela est particulièrement préférable au cas où l'utilisateur modifierait l'heure de la réunion). Quoi qu'il en soit, la raison principale est de pouvoir restaurer l'heure de création d'origine afin que l'utilisateur puisse s'y référer.

2
Petr Abdulin