Webアプリケーションでタイムゾーンをどのように処理できますか？

次のユーザーストーリーについての理解を深めたいです。

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

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

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

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

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

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

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

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

タイムスタンプの保存の問題は簡単です。それらをUTCに保存します。

それらを表示することに関しては、デバイスのタイムゾーン設定を取得し、それを現在のタイムゾーンとして使用することは理にかなっています。つまり、「時間入力」ボックスの横にタイムゾーンドロップダウンがあるはずです。これはデフォルトでデバイスの現在のタイムゾーンになり、ユーザーは必要に応じて変更できます。

ユーザーの大多数はおそらくタイムゾーンをあまり変更しないか、まったく変更しません。ほとんどの場合、あなたが概説した状況はまれです。適切なデフォルトでドロップダウンを実装することで、移動する人にとって十分簡単なものにすることができます（通常、旅行者以外の人がタイムゾーンをよく理解しているためです）。

実際には、アプリが最初に実行されたときにデバイスが設定されていたタイムゾーンを保存し、それが変更されるかどうかを確認することをお勧めします。変更された場合、ユーザーはおそらく旅行者であり、タイムゾーンドロップダウンがあるとおそらくメリットがあります。それ以外の場合は、ドロップダウンを表示せず、デフォルトでデバイスのタイムゾーンに設定します（ユーザーがそれらについて知る必要がないため）。どちらの場合も、ユーザーがタイムゾーンドロップダウンを手動で表示/非表示にできる設定をアプリに設定します。

上記を要約すると：

• 最初の実行時に、デバイスが設定されているタイムゾーンを保存します。
• そのタイムゾーンをデフォルトのタイムゾーンとして使用します。常にそのタイムゾーンを想定してください。
• デバイスがタイムゾーンを切り替える場合は、ドロップダウンを追加して、イベントが存在するタイムゾーンを選択します。デフォルトでは、デバイス自体のタイムゾーンになります。
• このタイムゾーンのドロップダウンを手動で表示/非表示にするオプションを追加します。
• タイムスタンプは常にUTCで保存します。

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

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

「ハッピーニューイヤー」などのカスタマイズされた通知をWebアプリのすべてのユーザーに送信できる、同様の使用例を解決する必要がありました。ユーザーは世界中に分散しているため、タイムゾーンに従って通知を表示する必要がありました。タイムスタンプをUTCに保存することは、問題なくうまく機能しました。

ユースケースでは、ユーザーのタイムゾーンをどこかに保存していない場合、gmapsのようなある種の位置検出の使用を開始しない限り、ユーザー入力を求めずに検索結果を正確に返すことはできませんが、それはそうではありません。信頼できる。そのため、毎回タイムゾーンを尋ねて、ユーザーがウェブサイトに何を入力しているのかを確認する必要があります。

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

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

1. UTC。単純にする。

2. ユーザーに最も関連のあるタイムゾーンを使用します。

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

   インターフェイスが煩雑にならない場合は、イベントのタイムゾーンとローカルタイムゾーンで日付を表示できます（例：2012-06-13 09:00 EST（2012-06-12 19:00 EDT））。

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

   繰り返しますが、ユーザーに最も関連するタイムゾーン（イベントのタイムゾーンなど）の検索に重点を置き、これらの結果を検索結果で優先しますが、ユーザーに関連する他のタイムゾーンに一致するイベント（たとえば、現地時間）。これを行う場合、特に一致するテキストを強調表示する場合は、一致するタイムゾーンでイベントの日付を表示する必要があります。

ここでは、実装の実現可能性についてあまり気にすることなく、最高のユーザビリティを提案します。
1.イベントをdbに保存する最初の問題については、誰でもそれをUTCに保存することに同意します

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

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

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

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

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

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

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

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

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

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

1. GPS

2. HTML5機能。

3. Javascript機能

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

解決策：明らかにUTC、私は以下の手順を重ねました：

ステップ1. ジオロケーションジオロケーションAPIを使用して、ユーザーの

    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.（Long、Lat）をYahoo APIのような（Lat、Long）to TimeZone apiの引数として（フラグRを使用してLatitudeをタイムゾーンに変換して）ユーザーのタイムゾーンを取得します。

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

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

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

UIの場合

=> Google Calendar APIまたは一部のCalendar APIを使用する

関連資料：

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

2. 緯度経度からのタイムゾーン検索

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

それが役に立てば幸い！

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

会議があります：

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

またはそのようなもの。もう1つの方法は、作成タイムゾーンを保存し、実行時に変換することです（これは、ユーザーが会議時間を変更する場合に特に適しています）。どちらの場合も、ユーザーが参照できるように元の作成時刻を復元できるようにすることが主な理由です。

1. タイムスタンプをデータベースに保存する方法

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

注：get-goからローカル時間を保存できますが、ユーザーがイベントを検索するときに、ローカル時間への変換が存在することを望みます。また、サーバーがクライアントのタイムゾーンを検出できることを願っています。

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

「九時」のためのユーザーの検索は、私は、UTCのいずれかで「9:00」を含むイベントを検索すると考えOR creation time OR現地時間。結果については、結果の表を1つ表示しますcreation time（これは、ユーザーがどこでイベントを作成したかをユーザーが探していると想定しているため、異なるタイムゾーンで作成された可能性のあるタイムスタンプを表示することを目的としています）。 、関連する結果を含む2番目の結果の表を表示します。ヘッダーには「探しているものではありませんか？関連する結果を表示してください」と表示されます（これらには残りのUTCと現地時間の結果が含まれます）。

全体として、UTC時間、現地時間、、creation timeおよびcreation time zone、、（つまり、作成されたイベントの現地時間とタイムゾーン）をUTC時間で並べ替えて表示します。これにより、2つの異なる場合に、どのイベントが最初に来るかを確認できます。イベントは2つの異なるタイムゾーンで9:00にスケジュールされました。