Webアプリでタイムゾーンを処理するにはどうすればよいですか？
次のユーザーストーリーをよりよく理解したいと思っています。
ジョンはシドニーで働いています。午前9時に、彼はチューリッヒのサーバーで実行されるWebアプリにイベントを記録します。翌日、彼はイベントを議論する緊急会議のためにニューヨークに旅行します。会議中、彼は日付と時刻でイベントを検索します。
ご覧のとおり、ここには少なくとも2つの問題があります。
- データベースにタイムスタンプを保存する方法
- UIでどのように表示する必要がありますか
Johnがイベントを検索すると、彼は9:00に発生したことがわかりますが、Webブラウザーに何を入力すべきですかタイムスタンプとして「9:00」を入力しただけでは何も見つかりません。これは、チューリッヒ時間またはニューヨーク時間である可能性があるためです（イベントが見つからないため、アプリはシドニーで発生したことを知る方法がないため、正しいタイムゾーンを自動的に選択することはできません）。
タイムゾーンを含む可能性のあるタイムスタンプをユーザーに尋ねる良い方法は何ですか？
2番目の問題は、結果を表示する方法です。世界中のチームがイベントについて議論する必要がある場合（および関連するイベントを見つける場合は、世界中の複数のサイトを一度に標的とするクラッカー攻撃を考えてください）。
別のタイムゾーンで作成されたタイムスタンプを表示する良い例は何ですか？
注：要件の有用性に集中してください。データベースマッピングを自分で把握できます。現在、私はワークフローについて確信が持てません。必要な情報を非侵入的/直感的な方法で尋ねる/提示する必要があります。可能であれば、既にこれを解決している既存のWebアプリへのリンクを提供します。
タイムスタンプの保存の問題は簡単です。UTCで保存します。
それらを表示するには、デバイスのタイムゾーン設定を取得し、それを現在のタイムゾーンとして使用するのが理にかなっています。そうは言っても、「time input」ボックスの横にタイムゾーンのドロップダウンがあるはずです。デフォルトではデバイスの現在のタイムゾーンになっているため、ユーザーは必要に応じて変更できます。
ほとんどのユーザーは、おそらくタイムゾーンをあまり変更しないか、まったく変更しないでしょう。ほとんどの場合、あなたが概説した状況はまれです。適切なデフォルトでドロップダウンを実装することで、動き回る人にとって物事を簡単にすることができるはずです（通常、旅行者よりもタイムゾーンをよく理解しているため）。
実際、アプリが最初に実行されたときにデバイスに設定されたタイムゾーンを保存し、それが変更されるかどうかを確認することはさらに良いでしょう。変更された場合、ユーザーはおそらく旅行者であり、タイムゾーンのドロップダウンを使用することで恩恵を受けるでしょう。そうでない場合は、ドロップダウンを表示せず、デフォルトでデバイスのタイムゾーンを使用します（ユーザーがそれらについて知る必要がないため）。いずれの場合も、ユーザーがタイムゾーンのドロップダウンを手動で表示/非表示できるようにアプリで設定してください。
上記を要約するには：
- 最初の実行時に、デバイスに設定されているタイムゾーンを保存します。
- そのタイムゾーンをデフォルトのタイムゾーンとして使用します。常にそのタイムゾーンを想定してください。
- デバイスがタイムゾーンを切り替える場合、ドロップダウンを追加して、イベントが含まれるタイムゾーンを選択します。デフォルトはデバイスのタイムゾーンです。
- このタイムゾーンドロップダウンを手動で表示/非表示するオプションを追加します。
- タイムスタンプは常にUTCで保存します。
通常、アプリケーションでは、フォーラムサイトでよく見られるように、最初の登録時にユーザーのタイムゾーンを保存し、常にタイムゾーンで時間を表示します。
日付の保存に関しては、UTCが最適です。 UTCに変換し、データベースに貼り付けます。取得しながら、時間をユーザーに設定されたタイムゾーンに変換するだけです。
「Happy New Year」などのカスタマイズされた通知をWebアプリのすべてのユーザーに送信できる同様のユースケースを解決する必要がありました。ユーザーは世界中に広がっているため、タイムゾーンに従って通知を表示する必要がありました。タイムスタンプをUTCで保存することは、問題なくうまく機能しました。
あなたのユースケースでは、ユーザーのタイムゾーンをどこかに保存していない場合、gmapsのような何らかの位置検出の使用を開始しない限り、ユーザー入力を求めずに検索結果を正確に返すことはできませんが、そうではありません信頼できる。そのため、ユーザーがWebサイトに入力している内容をユーザーが確実に把握できるように、毎回タイムゾーンを要求する必要があります。
タイムゾーン情報がある場合は、タイムゾーン設定を使用してWebアプリ全体を実行する必要があります。したがって、ユーザーが9:00を検索すると、シドニーのタイムゾーンで検索されます。一方、ニューヨークに座ってイベントを作成する場合、シドニーのタイムゾーンでイベントを作成します。日付を表示しながら常にタイムゾーンを表示することにより、このようなケースを解決します。
それが役に立てば幸い！ :)
UTC。複雑にしないでおく。
ユーザーに最も関連性のあるタイムゾーンを使用します。
ユーザーがイベントのためにシドニーにいる、またはシドニーに旅行していることがわかっている場合、イベントへのトランスポートを手配するときに、そのタイムゾーンで思考になります。彼らが現在ニューヨークにいるという事実はほとんど無関係です。そしてもちろん、アプリがさまざまなタイムゾーンで日付を表示する場合、常に日付の隣にタイムゾーンを表示する必要があります。 9:00 EST。
インターフェースが煩雑にならない場合は、イベントのタイムゾーンとローカルのタイムゾーンで日付を表示できます。 2012-06-13 09:00 EST（2012-06-12 19:00 EDT）。
検索も同様の問題であると主張しますが、警告が1つあります：誤検知は許容できます（期待していなかった結果が得られます）が、誤検知は我慢できません（期待した結果が得られません）。
繰り返しになりますが、ユーザーに最も関連するタイムゾーン（イベントのタイムゾーンなど）の検索に焦点を当て、検索結果でこれらの結果を優先しますが、ユーザーに関連する他のタイムゾーンに一致するイベント（たとえば、現地時間）。これを行う場合、特に一致するテキストを強調表示する場合は、一致するタイムゾーンでイベントの日付を表示する必要があります。
ここでは、実装の実現可能性についてあまり気にすることなく、最高の使いやすさを提案しています。
1。 dbにイベントを保存する最初の問題については、誰もがUTCにイベントを保存することに同意します
2。最高のユーザーエクスペリエンスを提供するには、ユーザーのタイムゾーンの履歴を保存します。タイムゾーンの変更のタイムスタンプを保存できれば、さらに良いでしょう。これにより、毎回タイムゾーンを明示的に指定することなく、ユーザーが自由にクエリできるようになります。
これらの機能を使用して、Johnによる「9.00」だけの検索クエリの処理方法を見てみましょう。
上記の機能により、Johnはこれまで2つのタイムゾーンにいたことがわかりました（または、上記の期間のタイムゾーンリストを取得します）。そこで、シドニーのタイムゾーンからUTCまでの9.00を変換して、クエリを実行します。また、9.00をNewYorkタイムゾーンからUTCに変換し、クエリを起動します。結果として、Johnに2行を表示して、シドニーで9.00に、ニューヨークで9.00に彼が行ったことを表示します。この場合、ニューヨーク行は空白になりますが、このタイムゾーンも検索したことをユーザーに通知するために、ユーザーにまだ表示する必要があると思います。
3.タイムゾーンを含む可能性のあるタイムスタンプをユーザーに尋ねる良い方法は何ですか？
彼のタイムゾーンが最近変更された場合、彼がアプリケーションにログインするたびに、デフォルトのタイムゾーンがネイティブのタイムゾーンに変更されることを通知する必要があります。
イベントの作成中に、ユーザーがドロップダウンからタイムゾーンを選択するとします。世界のすべてのタイムゾーンのオプションを指定することでユーザーに負担をかけません。ドロップダウンの最初のオプションはユーザーのデバイスの現在のタイムゾーンです。その後、タイムゾーンの履歴からタイムゾーン、UTC、そしてそれまでに使用したことのない残りのタイムゾーンが表示されます。
4.世界中のチームがイベントについて議論する必要がある場合、結果を表示する方法：
このユースケースを2つ以上のチーム数に分割したいと思います。
たった2つのチームについて、各チームがローカルタイムゾーンと他のチームのタイムゾーンでタイムスタンプを表示することを希望します。 （個人的には、会議をスケジュールする際の都合上、相手のタイムゾーンで話すことを好みます）。 2チーム以上の場合、より一般的なタイムゾーン（UTC）を検討することをお勧めします。したがって、この場合、すべてのユーザーは、UTCとデフォルトのタイムゾーンの2つのタイムゾーンでタイムスタンプを確認する必要があります。
これらの提案は、ユーザーが現地時間で計算を行う必要はないが、同時に好みのタイムゾーンで流otherに他のユーザーと通信できるようにすることを意図しています。
[OK]を私は他とは異なるアプローチを得た：
まず、事前にいくつかのことを想定しました。
イベントをリストしている人にはスマートフォンがあります（ブラウザの場合、これらの仮定をする必要はありません）：
GPS
HTML5機能。
Javascript機能
タイムスタンプをデータベースに保存するにはどうすればよいですか？
解決策：明らかに[〜＃〜] utc [〜＃〜] 、以下の手順を重ねました：
手順1. Geolocation APIを使用して、ユーザーの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. Yahoo API （LatitudeをTimezoneに変換するにはFlag Rを使用）のようなTimeZone APIの一部の（Lat、Lat）の引数として（Long、Lat）を与えますユーザーのタイムゾーン。
=>ユーザーのタイムゾーンは、ユーザーの入力なしで決定されます（ユーザーが住んでいる場所のタイムゾーンをユーザーが知っていると単純に仮定できないため、これを使用しています私のタイムゾーンを知っているのは、数か月後か、その場所で何かをした後です：P、かなりばか！）
各イベントテーブルにはTimezone、Eventがあり、CityNameを持つこともできます。次に、CityNamesに基づく分類で別のデータベーステーブルを作成します。そのため、ユーザーには2つの列があります
|---------------------------------------|
|_____NewYork________|______Sydney______|
| | |
|Event 1 | Event 2 |
|____________________|__________________|
UI用
=> Google Calendar APIまたはいくつかのCalendar APIを使用する
関連資料：
私は、この問題を解決する方法をいくつか示しています。ただし、デバイスAPIを使用してタイムゾーンが決定されると、ユーザーにどの程度正確かつ軽量になるかを確認してください
それが役に立てば幸い！
- データベースにタイムスタンプを保存する方法
イベントの作成時に、UTC時間とローカルタイムゾーン（別名creation time zone）。 UTC時間をローカル時間（別名creation time）およびUTC時間とcreation time zone。
注：get-goから現地時間を保存できますが、ユーザーがイベントを検索するときに、現地時間への変換が存在することを望みます。また、サーバーがクライアントがどのタイムゾーンにいるかを検出できることを願っています。
- UIでどのように表示する必要がありますか
ユーザーが「9:00」を検索するとき、UTCに「9:00」を含むイベントを検索します[〜＃〜] or [〜＃〜]creation time[〜＃〜] or [〜＃〜]現地時間。結果については、creation time（これは、ユーザーがどこにいてもイベントを作成した時間を探していると想定されるため、異なるタイムゾーンで作成されたタイムスタンプを表示することを目的としています）関連する結果、おそらく「あなたが探しているものではないのですか？関連する結果を見る」というヘッダーがあります（これらには、残りのUTCおよび現地時間の結果が含まれます）。
全体的に、UTC時間、現地時間、creation time、 そしてその creation time zone（つまり、作成されたイベントの現地時間とタイムゾーン）はUTC時間でソートされているため、2つの異なるタイムゾーンで2つの異なるイベントが9:00にスケジュールされている場合、最初に来るイベントを確認できます。
その特定の場合、bothローカル時間とUTC時間を保存します。 UTCはややメジャーであり、現在のタイムゾーンへの時刻の同期と変換に使用されます。ローカルは、次のような検索および追加情報に使用されます。
会議があります：
12:00 Monday (UTC)
9:00 Monday (Sydney, creation local time)
11:00 Monday (Zurich, local time)
またはそのようなもの。もう1つの方法は、作成タイムゾーンを保存し、実行時に変換することです（これは、ユーザーが会議時間を変更する場合に特に適しています）。いずれにしても、主な理由は、ユーザーが参照できるように元の作成時間を復元できるようにすることです。