Comment gérer les fuseaux horaires dans mon webapp?

la question du stockage des horodateurs est simple: conservez-les dans UTC.

quant à leur affichage, il serait logique de prendre le réglage du fuseau horaire de l'appareil et de l'utiliser comme fuseau horaire courant. Cela dit, il devrait y avoir un dropdown de fuseau horaire à côté de la boîte "time input", qui est par défaut le fuseau horaire courant du périphérique, de sorte que l'utilisateur puisse le changer si nécessaire.

la majorité de vos utilisateurs ne changeront probablement pas beaucoup de fuseaux horaires, ou pas du tout. Pour la plupart du temps, la situation que vous avez décrite est rare. En mettant en place un dropdown avec un défaut approprié, vous devriez être en mesure de rendre les choses assez facile pour ceux qui ne se déplacent (parce qu'ils ont généralement une meilleure compréhension des fuseaux horaires qu'un non-voyageur).

en fait, ce serait encore mieux de sauvegarder le fuseau horaire dans lequel le périphérique a été réglé lorsque votre application a été lancée, et ensuite de voir si elle change un jour. Si elle change, alors l'utilisateur est probablement un voyageur et il serait probablement préférable de laisser tomber le fuseau horaire. Sinon, n'affichez pas le dropdown et le timezone par défaut du périphérique (car l'utilisateur n'a pas besoin de les connaître). Dans les deux cas, avoir un paramètre dans l'application qui permet à l'utilisateur d'afficher/cacher manuellement le dropdown du fuseau horaire.

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

• lors de la première sortie, enregistrez le fuseau horaire du périphérique.
• Use que le fuseau horaire le fuseau horaire par défaut. Toujours supposer que le 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 est, en cas de défaut de fonctionnement du fuseau horaire de l'appareil.
• ajouter une option pour afficher/cacher ce dà © clin de fuseau horaire manuellement.
• stocke toujours les horodateurs dans UTC.

dans nos applications, nous stockons généralement le fuseau horaire de l'utilisateur lorsque nous nous enregistrons pour la première fois, comme souvent vu sur les sites de forum, et toujours afficher l'heure avec le fuseau horaire .

quant à la conservation des dates, UTC est la voie à suivre. Convertissez en UTC et collez-le 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 dû résoudre un cas d'utilisation similaire, où les notifications personnalisées, comme "Bonne Année", pourrait être envoyé à tous les utilisateurs de l'application web. Puisque les utilisateurs sont répartis dans le monde entier, nous avons dû afficher la notification en fonction du fuseau horaire. Le stockage de l'horodatage dans UTC a bien servi notre but, 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 l'entrée de l'utilisateur, à moins que vous ne commenciez à utiliser une sorte de détection d'emplacement comme le fait gmaps, mais ce n'est pas fiable. Vous aurez donc besoin de demander le fuseau horaire à chaque fois pour s'assurer que l'utilisateur sait ce qu'il entre dans le site.

si vous avez des informations sur le fuseau horaire, l'application web entière devrait être lancée avec le réglage du fuseau horaire. Par conséquent, quand l'utilisateur fait la recherche pour 9:00, Il sera à la recherche avec le fuseau horaire de Sydney. D'un autre côté, s'il crée un événement pendant qu'il est assis à New York, il créera un événement avec le fuseau horaire de Sydney. Nous résolvons ces cas par toujours affichage du fuseau horaire lors de l'affichage des dates.

Espère que cela aide! :)

1. UTC. Garder les choses simples.

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

   si vous savez que L'utilisateur va être dans ou voyager à Sydney pour l'événement, alors ils seront penser dans ce fuseau horaire lors de l'organisation du transport à l'événement. Le fait qu'ils soient actuellement à New York est largement hors de propos. Et bien sûr, si votre application montre des dates dans une variété de timezones, il doit toujours montrer 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 le fuseau horaire local, par exemple 2012-06-13 09:00 HNE (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 pouvons pas supporter les faux négatifs (ne pas obtenir un résultat auquel nous nous attendions).

   encore une fois, je me concentrerais sur la recherche du fuseau horaire le plus pertinent pour l'utilisateur (e.g. event timezone), et donner la priorité à ces résultats dans les résultats de recherche, mais vous pouvez également renvoyer des événements qui correspondent dans d'autres fuseaux horaires qui sont pertinents pour l'utilisateur (e.g. 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 la meilleure utilisabilité sans se soucier beaucoup de la faisabilité de la mise en œuvre.

1. Pour la première édition de stocker des événements dans db, tout le monde serait d'accord pour 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 sauver horodatage de changement de fuseau horaire, encore mieux. Cela nous permettra de donner la liberté à l'utilisateur de demander sans spécifier fuseau horaire explicitement à chaque fois.

ainsi, avec ces caractéristiques, voyons comment Recherche requête de juste "9.00" par John sera manipulé:

avec les caractéristiques mentionnées ci-dessus, maintenant je sais que John a été dans 2 timezones jusqu'à la date(ou obtenir la liste des timezones pour période mentionnée) . Donc je vais couvrir 9h00 du fuseau horaire de Sydney à L'UTC, incendie d'une requête. Conversion également 9.00 du fuseau horaire de NewYork en UTC, fire a requête. En conséquence Je montrerai 2 lignes à John montrant ce qu'il a fait à 9h00 à sydney et 9h00 à 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.Quelle est une bonne façon de demander à l'utilisateur un horodatage qui pourrait inclure le fuseau horaire?

si son fuseau horaire est récent changé, chaque fois qu'il se connecte dans l'application, un avis doit être donné, votre fuseau horaire par défaut est modifié au fuseau horaire natif.

lors de la création d'un événement, disons que l'utilisateur sélectionne fuseau horaire partir de la liste déroulante.Ne pas encombrer l'utilisateur en donnant des options de tous les fuseaux horaires du monde.La première option de dropdown devrait être l'heure actuelle. horaire de l'utilisateur de l'appareil. après cela, les souvenirs de son histoire timezones, puis UTC et puis timezones restants qu'il n'a jamais utilisé jusqu'à date.

4.Comment afficher les résultats, si des équipes du monde entier ont besoin de 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 voit horodatage dans son fuseau horaire local et le fuseau horaire de l'autre équipe. (Je préfère personnellement parler dans le fuseau horaire d'une personne à l'autre extrémité pour sa commodité lors de la planification d'une réunion). Pour plus de 2 équipes, ses il est préférable d'envisager un fuseau horaire plus commun, C'est-à-dire UTC. Donc dans ce cas, tous les l'utilisateur devrait voir timestamp en 2 temps, en UTC et par défaut fuseau.

ces suggestions sont données avec l'intention que l'utilisateur ne doit pas faire de calcul dans son heure locale, mais en même temps, il devrait être en mesure de communiquer avec d'autres utilisateurs couramment dans leur fuseau horaire préféré.

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

tout d'abord, j'ai supposé peu de choses avant main.

la personne qui inscrit un événement a un smartphone (si c'est un navigateur, Je n'ai pas à faire ces hypothèses) avec:

1. GPS

2. HTML5 capability.

3. Javascript

Comment enregistrer les horodatage dans la base de données?

Solution: évidemment UTC , I procédure superposée ci-dessous:

Étape 1. Utilisez le géolocalisation de l'utilisateur en utilisant 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 les arguments (Long,Lat) à certaines api de (Lat, Long) à TimeZone comme le Yahoo API (utilisez le drapeau R pour obtenir la Latitude convertie en fuseau horaire) pour obtenir le fuseau horaire des utilisateurs.

= > le fuseau horaire de l'utilisateur est déterminé sans l'entrée de l'utilisateur (Je l'utilise parce que vous ne pouvez pas simplement supposer que l'utilisateur connaît le fuseau horaire de l'endroit où il vit, je savais mon fuseau horaire seulement après quelques mois ou quelque chose à l'endroit :P, assez stupide!)

la table de chaque événement a Timezone , Event et peut donc aussi avoir CityName Ensuite, créez une autre table de base de données 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

= > utilisez L'API calendrier Google ou une partie de L'API calendrier

Lectures Connexes:

1. déterminer le fuseau horaire à partir de latitude / longitude sans utiliser des services web comme Geonames.org

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

je sais qu'il s'agit juste de montrer une idée comment résoudre ce problème. Mais voir comment précis et léger il devient sur les utilisateurs lorsque le fuseau horaire est déterminé en utilisant APIs de l'appareil

espérons aide!

dans ce cas particulier, je stockerais à la fois heure locale et UTC. UTC est un peu majeur et utilisé pour la synchronisation et la conversion du temps au 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 façon est de stocker le fuseau horaire de création, et de convertir à l'exécution (c'est particulièrement mieux au cas où l'utilisateur changera de réunion temps.) Dans les deux cas, la raison principale est d'être capable de restaurer le temps de création original pour que l'utilisateur puisse s'y référer.

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

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

NOTE: je peux stocker l'heure locale depuis le début, mais quand l'utilisateur fait une recherche pour un événement, je voudrais espérons qu'une conversion à l'heure locale existe. J'espère aussi que le serveur détecte l'horaire, le client est en.

1. Comment dois-je vous les présente dans l'INTERFACE utilisateur

Lorsqu'un utilisateur recherche" 9:00", je rechercherais des événements qui incluent" 9:00 "dans L'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 des horodateurs qui peuvent avoir été créés dans un fuseau horaire différent, car nous supposons que l'utilisateur est à la recherche de l'heure à laquelle il a créé un événement, où qu'il se trouve.), et l'affichage d'un second tableau de résultats ci-dessous, des résultats, peut-être avec l'en-tête, "non Pas ce que vous cherchez? Voir les résultats connexes " (ceux-ci comprennent les restes UTC et les résultats de l'heure locale).

dans L'ensemble, j'afficherais L'heure UTC, l'heure locale, le creation time , et le creation time zone (c.-à-d. l'heure locale et le fuseau horaire de l'événement où il a été créé) trié par heure UTC, de sorte que vous pouvez voir quel événement vient en premier, au cas où deux événements différents étaient prévus pour 9h00 dans deux fuseaux horaires différents.