web-applications - Web アプリケーションでタイム ゾーンを処理するにはどうすればよいですか?

Question

次のユーザー ストーリーの理解を深めたいと考えています。

ジョンはシドニーで働いています。朝 9:00 に、彼はチューリッヒのサーバーで実行されている Web アプリにイベントを記録します。翌日、彼は緊急会議のためにニューヨークに移動し、イベントについて話し合う必要があります。会議中、彼は日付と時刻でイベントを検索します。

私が見たところ、ここには少なくとも 2 つの問題があります。

1. タイムスタンプをデータベースに保存するにはどうすればよいですか
2. UI でそれらをどのように表示する必要がありますか

ジョンがイベントを検索すると、それが 9:00 に発生したことがわかりますが、Web ブラウザーに何を入力すればよいでしょうか? タイムスタンプとして「9:00」と入力しただけでは、何も見つかりません。これは、チューリッヒまたはニューヨークの時間である可能性があるためです (イベントが見つからないため、アプリはシドニーで発生したことを知る方法がありません。正しいタイム ゾーンを自動的に選択することはできません)。

タイムゾーンを含む可能性のあるタイムスタンプをユーザーに尋ねる良い方法は何ですか?

2 番目の問題は、結果を表示する方法です。世界中のチームがイベントについて話し合う必要がある場合 (および関連するイベントを見つける必要がある場合は、世界中の複数のサイトを同時に標的とするクラッカー攻撃を考えてください)。

別のタイム ゾーンで作成された可能性のあるタイムスタンプを表示する良い例は何ですか?

注: 要件の使いやすさに集中してください。データベースのマッピングを自分で把握できます。現在、ワークフローについてはよくわかりません。非侵入的/直感的な方法で必要な情報を尋ねたり、提示したりする必要があります。可能であれば、既にこれを解決している既存の Web アプリへのリンクを提供してください。

Answer 1

私たちのアプリケーションでは、フォーラムサイトでよく見られるように、通常、最初に登録したときのユーザーのタイムゾーンを保存し、常にタイムゾーンで時間を表示します。

日付の保存に関しては、UTCが最適です。UTCに変換し、データベースに貼り付けます。取得中に、時間をユーザーに設定されたタイムゾーンに変換するだけです。

「明けましておめでとう」などのカスタマイズされた通知をWebアプリのすべてのユーザーに送信できる、同様のユースケースを解決する必要がありました。ユーザーは世界中に分散しているため、タイムゾーンに応じて通知を表示する必要がありました。UTCでタイムスタンプを保存することは、問題なく、私たちの目的をうまく果たしました。

ユースケースでは、ユーザーのタイムゾーンをどこかに保存していない場合、gmapsのような何らかの場所検出を使用し始めない限り、ユーザー入力を求めずに検索結果を正確に返すことはできませんが、そうではありません。信頼できる。したがって、ユーザーがWebサイトに何を入力しているのかをユーザーが確実に把握できるように、毎回タイムゾーンを要求する必要があります。

タイムゾーン情報がある場合は、Webアプリ全体をタイムゾーン設定で実行する必要があります。したがって、ユーザーが9:00を検索すると、シドニーのタイムゾーンで検索されます。一方、ニューヨークに座っているときにイベントを作成する場合は、シドニーのタイムゾーンでイベントを作成します。このような場合は、日付を表示しながら常にタイムゾーンを表示することで解決します。

それが役に立てば幸い！:)

Answer 2

1. UTC。複雑にしないでおく。

2. ユーザーに最も適したタイムゾーンを使用してください。

   ユーザーがイベントのためにシドニーにいる、またはシドニーに旅行することがわかっている場合、ユーザーはイベントへの交通手段を手配するときにそのタイムゾーンで考えます。彼らが現在ニューヨークにいるという事実はほとんど関係ありません。もちろん、アプリがさまざまなタイムゾーンで日付を表示する場合は、日付の横に常にタイムゾーンを表示する必要があります (例: 09:00 EST )。

   インターフェースが煩雑にならなければ、イベントのタイムゾーンとローカルのタイムゾーンで日付を表示できます (例: 2012-06-13 09:00 EST (2012-06-12 19:00 EDT) )。

   検索も同様の問題であると主張しますが、注意点が 1 つあります。誤検出 (予期していなかった結果が得られる) は許容できますが、誤検出 (期待した結果が得られない) には耐えられません。

   ここでも、ユーザーにとって最も関連性の高いタイムゾーン (例: イベントのタイムゾーン) の検索に焦点を当て、検索結果でこれらの結果を優先しますが、ユーザーに関連する他のタイムゾーン (例: タイムゾーン) に一致するイベントを返すこともできます。現地時間）。これを行う場合、特に一致するテキストを強調表示する場合は、一致するタイムゾーンでイベントの日付を表示する必要があります。

Answer 3

ここでは、実装の実現可能性についてあまり気にせずに、最高の使いやすさを提案しています。
1. イベントを db に保存する最初の問題では、誰もが UTC で保存することに同意します

。 2. 最高のユーザー エクスペリエンスを提供するために、ユーザーのタイムゾーンの履歴を保存します。タイムゾーン変更のタイムスタンプを保存できれば、なおさらです。これにより、タイムゾーンを毎回明示的に指定しなくても、ユーザーが自由にクエリを実行できるようになります。

したがって、これらの機能を使用して、ジョンによる「9.00」の検索クエリがどのように処理されるかを見てみましょう:
上記の機能により、ジョンが日付まで 2 つのタイムゾーンにいたことがわかりました (または、上記の期間のタイムゾーン リストを取得します)。そこで、シドニーのタイム ゾーンから UTC に 9.00 を変換し、クエリを実行します。また、9.00 を NewYork タイム ゾーンから UTC に変換し、クエリを実行します。結果として、ジョンがシドニーで 9.00 に、ニューヨークで 9.00 に何をしたかを表示する 2 つの行を表示します。この場合、New york の行は空白になりますが、このタイム ゾーンも検索したことを知らせるためだけに、user に表示する必要があると思います。

3.タイムゾーンを含む可能性のあるタイムスタンプをユーザーに尋ねる良い方法は何ですか?

彼のタイムゾーンが最近変更された場合、彼がアプリケーションにログインするたびに、デフォルトのタイムゾーンがネイティブのタイムゾーンに変更されたという通知が表示されます。
イベントの作成中に、ユーザーがドロップダウンからタイムゾーンを選択するとします。世界のすべてのタイムゾーンのオプションを提供することでユーザーに負担をかけないようにします。ドロップダウンの最初のオプションは、ユーザーのデバイスの現在のタイムゾーンである必要があります。その後、彼のタイムゾーンの履歴からのタイムゾーン、UTC、そして彼がこれまで使用したことのない残りのタイムゾーン.

4.世界中のチームがイベントについて話し合う必要がある場合、結果を表示する方法:

この使用例を 2 チームまたは 2 チーム以上のチームに分割したいと思います。チームが 2 つだけの場合は
、各チームがローカル タイム ゾーンでタイムスタンプを表示し、他のチームのタイム ゾーンでタイムスタンプを表示することを希望します。(個人的には、会議をスケジュールする際に都合がよいように、相手のタイムゾーンで話すことを好みます)。2 つ以上のチームの場合は、より一般的なタイムゾーン、つまり UTC を検討することをお勧めします。したがって、この場合、すべてのユーザーは、UTC とデフォルトのタイムゾーンの 2 つのタイムゾーンでタイムスタンプを表示する必要があります。

これらの提案は、ユーザーが現地時間で計算を行う必要がないことを意図して提供されますが、同時に、他のユーザーと好みのタイムゾーンで流暢に通信できる必要があります。

Answer 4

わかりました、私は他の人とは異なるアプローチを取りました：

まず、事前にいくつかのことを想定しました。

イベントをリストしている人はスマートフォンを持っています（それがブラウザの場合、私はこれらの仮定をする必要はありません）：

1. GPS

2. HTML5機能。

3. Javascript機能

タイムスタンプをデータベースに保存するにはどうすればよいですか？

解決策：明らかにUTC、私は以下の手順をオーバーレイしました：

手順1.GeolocationAPIを使用してユーザーのGeolocationを使用する

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

ステップ2.YahooAPIのようなTimeZoneAPIの一部（Lat、Long）の引数として（Long、Lat）を指定し（フラグRを使用してLatitudeをタイムゾーンに変換します）、ユーザーのタイムゾーンを取得します。

=>ユーザーのタイムゾーンはユーザーの入力なしで決定されます（ユーザーが自分の住んでいる場所のタイムゾーンを知っていると単純に想定できないため、これを使用しています。私のタイムゾーンは数か月後か何かでしかわかりませんでした：P、かなりばかげています！ ）。

各イベントテーブルにはTimezone、があり、次のEventようにすることもできます。次に、 sCityName に基づく分類で別のデータベーステーブルを作成します。CityNameしたがって、ここでユーザーには2つの列があります

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

UIの場合

=> GoogleCalendarAPIまたはCalendarAPIの一部を使用する

関連する読み物：

1. Geonames.orgなどのWebサービスを使用せずに、緯度/経度からタイムゾーンを決定します

2. 緯度経度からのタイムゾーンルックアップ

私はそれがこの問題を解決する方法のいくつかのアイデアを示すことについてちょうど知っています。ただし、デバイスAPIを使用してタイムゾーンを決定すると、ユーザーにとってどれほど正確で軽量になるかを確認できます。

それが役に立てば幸い！

Answer 5

1. タイムスタンプをデータベースに保存するにはどうすればよいですか

イベントの作成時に、UTC 時間とローカル タイム ゾーン (別名creation time zone) を保存します。保存したものを使用して UTC 時間を現地時間 (別名 ) に変換しcreation time、UTC 時間とcreation time zone.

注：最初から現地時間を保存できますが、ユーザーがイベントを検索するときに、現地時間への変換が存在することを願っています。また、クライアントがどのタイムゾーンにいるかをサーバーが検出できることを願っています。

1. UI でそれらをどのように表示する必要がありますか

ユーザーが「9:00」を検索すると、UTCまたは 現地時間で「9:00」を含むイベントを検索しますcreation time 。結果については、結果の表を 1 つ表示しますcreation time(これは、別のタイム ゾーンで作成された可能性のあるタイムスタンプを表示することを目的としています。これは、ユーザーがどこにいてもイベントを作成した時刻を探していると想定しているためです)。をクリックし、関連する結果を含む 2 番目の結果テーブルを下に表示します。おそらく、"探しているものではありませんか? 関連する結果を参照してください" というヘッダーが付いています (これらには、残りの UTC と現地時間の結果が含まれます)。

全体として、UTC 時間、現地時間、creation timeおよびcreation time zone(イベントが作成された現地時間とタイム ゾーン) を UTC 時間で並べ替えて表示します。イベントは 2 つの異なるタイムゾーンで 9:00 に予定されていました。

Answer 6

その特定のケースでは、ローカル時間と UTC 時間の両方を保存します。UTC はややメジャーであり、時刻を現在のタイム ゾーンに同期および変換するために使用されます。Local は、次のような検索や追加情報に使用されます。

ミーティングがあります:

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

またはそのようなもの。もう 1 つの方法は、作成タイム ゾーンを保存し、実行時に変換することです (これは、ユーザーがミーティング時間を変更する場合に特に適しています)。いずれにせよ、主な理由は、ユーザーが参照できるように元の作成時間を復元できるようにすることです。