Comment gérer les fuseaux horaires dans ma webapp?

Question

Je suis à la recherche pour une meilleure compréhension de la suite du récit utilisateur:

John travaille à Sidney. À 9:00 le 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 dans laquelle l'événement doit être discuté. Au cours de la réunion, il est à la recherche pour les événements par date et heure.

Comme je le vois, il y a au moins deux questions se posent ici:

1. Comment dois-je enregistrer le temps de timbres dans la base de données
2. Comment dois-je présenter dans l'INTERFACE utilisateur

Quand Jean les recherches de l'événement, il va savoir que c'est arrivé à 9:00 mais que doit-il entrer dans le navigateur web? Il ne sera pas trouver quelque chose quand il n'entre dans "9:00" timestamp parce que peut-être Zurich ou, heure de New York (depuis l'événement n'a pas été trouvé, l'application n'a aucun moyen de savoir que c'est arrivé à Sidney, donc il ne peut pas automatiquement, sélectionnez le fuseau horaire correct).

Ce qui est un bon moyen de demander à l'utilisateur un timestamp qui peut inclure le fuseau horaire?

La deuxième question est comment faire pour afficher les résultats. Si des équipes de partout dans le monde besoin pour discuter de l'événement (et de trouver des événements, pensez à un pirate attaque qui cible plusieurs sites à travers le monde à la fois).

Ce qui est un bon exemple pour l'affichage des horodateurs qui ont été créés dans un autre fuseau horaire?

Remarque: Veuillez vous concentrer sur la facilité d'utilisation de l'exigence. Je peux comprendre la base de données de cartographie de moi-même. Actuellement, je ne suis pas sur le flux de travail. Il devrait demander/de présenter les informations nécessaires à un non-intrusives/manière intuitive. Si vous le pouvez, donnez un lien vers un site web existant application qui résout déjà présent.

Answer 1

La question du stockage des horodateurs est simple: Stocker au format UTC.

Comme pour les afficher, il serait judicieux de prendre l'appareil du fuseau horaire et de l'utiliser comme le fuseau horaire actuel. Cela dit, il devrait y avoir un fuseau horaire menu déroulant à côté de "l'entrée" de la boîte, qui est par défaut le dispositif actuel de fuseau horaire, de sorte que l'utilisateur peut le modifier si nécessaire.

La majorité de vos utilisateurs ne sera probablement pas de changement de fuseaux horaires beaucoup, ou pas du tout. Pour la plupart, la situation que vous avez décrite est rare. Par la mise en œuvre d'une liste déroulante avec un défaut, vous devriez être en mesure de faire des choses assez facile pour ceux qui ne se déplacer (car ils ont généralement une meilleure compréhension des fuseaux horaires de non-voyageur).

En fait, il serait encore mieux d'enregistrer le fuseau horaire de l'appareil a été réglé lors de votre app a été la première exécution, et ensuite voir si il ne change jamais. En cas de modification, l'utilisateur est probablement un voyageur et aurait sans doute l'avantage d'avoir la zone de liste déroulante. Sinon, il suffit de ne pas afficher la liste déroulante et par défaut de l'appareil fuseau horaire (parce que l'utilisateur n'a pas besoin de les connaître). Dans les deux cas, un paramètre dans le app qui permet à l'utilisateur manuellement afficher/masquer la zone de liste déroulante.

---

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

• À la première exécution, de sauver ce qu'fuseau horaire de l'appareil.
• Utiliser le fuseau horaire le fuseau horaire par défaut. Supposons toujours que le fuseau horaire.
• Si le commutateur de périphérique fuseaux horaires, ajouter une liste déroulante pour sélectionner le fuseau horaire de l'événement est, par défaut l'appareil est propre fuseau horaire.
• Ajout d'une option pour afficher/masquer cette déroulante fuseau horaire manuellement.
• Toujours stocker les horodatages en UTC.

Answer 2

Dans nos applications, nous sommes généralement en magasin le fuseau horaire de l'utilisateur, lors de notre première registres, comme souvent vu sur les sites de forum, et de toujours afficher l'heure, le fuseau horaire.

Comme pour le stockage de la date, l'heure UTC est le chemin à parcourir. Convertir à l'UTC et le coller dans la base de données. Lors de la récupération, il suffit de convertir l'heure du fuseau horaire défini pour l'utilisateur.

J'ai eu à résoudre un usage similaire de cas, où des notifications personnalisées, comme "Happy New year", pourrait être envoyé à tous les utilisateurs de l'application web. Puisque les utilisateurs sont répartis dans le monde entier, nous nécessaire à l'affichage de la notification selon le fuseau horaire. Stocker le timestamp au format UTC bien servi notre but, sans hoquet.

Dans votre cas, si vous n'êtes pas le stockage de l'utilisateur fuseau horaire, quelque part, vous ne serez jamais en mesure de retourner les résultats de la recherche, sans avoir à demander la saisie de l'utilisateur, sauf si vous démarrez à l'aide de la détection de l'emplacement, comme gmaps, mais qui n'est pas fiable. De sorte que vous aurez besoin de demander le fuseau horaire à chaque fois pour s'assurer que l'utilisateur sait ce qu'il est d'entrer dans le site web.

Si vous avez des informations sur le fuseau horaire, l'ensemble de l'application web doit être exécuté avec le paramètre de fuseau horaire. C'est pourquoi, lorsque l'utilisateur n'recherche pour 9:00, il va être à la recherche à Sydney le fuseau horaire. D'autre part, s'il crée un événement tout en siégeant à New York, il va créer l'événement avec le Sydney fuseau horaire. Nous avons résoudre de tels cas, toujours l'affichage de fuseau horaire lors de l'affichage des dates.

Espérons que cela aide! :)

Answer 3

1. L'UTC. Garder les choses simples.

2. Utiliser le fuseau horaire qui est le plus pertinent pour l'utilisateur.

   Si vous connaissez l'utilisateur va être dans ou à destination de Sydney pour l'événement, alors ils seront à penser que le fuseau horaire lors de l'organisation des transports à l'événement. Le fait qu'ils sont actuellement à New York, est largement hors de propos. Et bien sûr, si votre application dates de spectacles dans divers fuseaux horaires, il faut toujours montrer le fuseau horaire à côté de la date, par exemple , de 09:00 HNE.

   Si ce n'est pas l'encombrement de votre interface trop, vous pourriez afficher les dates dans le cas de fuseau horaire et de 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 ne pouvons tolérer de faux positifs (l'obtention d'un résultat l'on n'attendait pas), mais on ne supporte pas de faux négatifs (pas d'obtenir un résultat qui nous attendait).

   Encore une fois, j'avais l'accent sur la recherche la plus pertinente fuseau horaire de l'utilisateur (par exemple, l'événement fuseau horaire), et de donner à ces résultats en priorité dans les résultats de recherche, mais vous pouvez également retourner les événements qui correspondent dans d'autres fuseaux horaires qui sont pertinentes pour l'utilisateur (par exemple, 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.

Answer 4

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

2. Pour donner la meilleure expérience utilisateur, d'enregistrer l'histoire de fuseau horaire de l'utilisateur. Si vous pouviez enregistrer le timestamp de l'heure de changement de zone, encore mieux. Cela va nous permettre de donner la liberté à l'utilisateur d'interroger sans spécifier le fuseau horaire explicitement à chaque fois.

Donc, avec ces caractéristiques, voyons comment requête de recherche de "9.00" par Jean seront traités:
Avec les caractéristiques mentionnées ci-dessus, maintenant je sais que John a été de 2 fuseaux horaires jusqu'à la date(ou obtenir des fuseaux horaires de liste pour période mentionnée) . Donc je vais secrète de 9.00 à partir de Sydney fuseau horaire UTC, incendie d'une requête. Aussi convertir 9.00 à partir de NewYork fuseau horaire UTC, le feu de la requête. En conséquence, je vais vous montrer 2 rangées de Jean en affichant ce qu'il a fait à De 9h00 à sydney et à 9.00 à new york. New york ligne vide dans ce cas, mais je pense encore devrait être montré à l'utilisateur , juste pour informer lui que nous avons cherché pour ce fuseau horaire.

3.Ce qui est un bon moyen de demander à l'utilisateur un timestamp qui peut inclure le fuseau horaire?

Si son fuseau horaire est récemment changé, à chaque fois qu'il se connecte à l'application, un avis doit être donné, votre fuseau horaire par défaut est modifié natif de fuseau horaire.
Lors de la création de l'événement, permet de dire que l'utilisateur sélectionne l' fuseau horaire partir de la liste déroulante.Permet de ne pas le fardeau de l'utilisateur en donnant des options de tous les les fuseaux horaires du monde.La première option de la liste déroulante doit être à jour de temps horaire de l'utilisateur de l'appareil. après que les fuseaux horaires à partir de son histoire de fuseaux horaires, puis UTC et demeurant fuseaux horaires dont il n'a jamais utilisé jusqu'à la date.

4.Comment afficher les résultats, si des équipes de partout dans le monde besoin pour discuter de l'événement:

Je voudrais diviser ce cas d'utilisation entre le nombre d'équipes de 2 ou plus de 2.
Pour seulement 2 équipes, je préférerais que chaque équipe se voit dans son horodatage fuseau horaire local et d'autres de l'équipe de fuseau horaire. (Je préfère personnellement parler dans le fuseau horaire d'une personne à l'autre extrémité de son commodité lors de la planification d'une réunion). Pour plus de 2 équipes, ses mieux considérer les plus courantes fuseau horaire c'est à dire UTC. Donc dans ce cas, tous les l'utilisateur devrait voir le timestamp, 2 fuseaux horaires, l'heure UTC et en son par défaut le fuseau horaire.

Ces suggestion sont donnés avec l'intention que l'utilisateur n'a pas besoin de faire tout calcul de l'heure locale, mais en même il devrait être en mesure de communiquer avec d'autres utilisateurs couramment dans leur moment préféré de la zone.

Answer 5

Ok j'ai eu une approche différente de celle des autres:

Tout d'abord, j'ai pris quelques petites choses avant de la main.

Personne qui est l'inscription de l'événement a smartphone(si c'est un navigateur, je n'ai pas à faire de ces hypothèses) avec:

1. GPS

2. HTML5 capacité.

3. Javascript

Comment dois-je enregistrer le temps de timbres dans la base de données?

Solution: bien Évidemment l'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. Donner le (Long,Lat) comme arguments pour certains (Lat,Long) au Fuseau horaire de l'api comme l' API Yahoo (use R pour obtenir la Latitude converti au Fuseau horaire) pour obtenir les utilisateurs de fuseau horaire.

=> Les utilisateurs de fuseau horaire est déterminé sans intervention de l'utilisateur ( je suis en utilisant ce parce que vous ne pouvez pas vous contenter de supposer que l'utilisateur connaît le fuseau horaire de l'endroit où il vit, je savais que mon fuseau horaire seulement après quelques mois ou quelque chose à la place :P, assez bête!)

Chaque Événement de la table a Timezone, Event & peut donc aussi avoir CityName Puis créer une autre table de base de données avec une classification basée sur CityNames. Donc, ici, l'utilisateur dispose de deux colonnes

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

Pour l'INTERFACE utilisateur

=> utiliser Google Calendar API ou de certains de le Calendrier de l'API

Lectures:

1. Déterminer le fuseau horaire à partir de la latitude/longitude, sans l'aide de services web comme Geonames.org

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

Je sais que sa fait de montrer une idée de comment résoudre ce problème. Mais voyez quelle est la précision et de la lumière-poids, il devient sur les utilisateurs lorsque le Fuseau horaire est déterminé par l'utilisation de l'appareil api Espère que cela aide!