タイムゾーンの選択をよりユーザーフレンドリーにする方法は？
タイムゾーンのリスト はかなり長く、多くの重複があり、エンドユーザーはもちろん、プログラマーにとってもあまり親切ではありません。
リストをより親しみやすく、80％以上のユーザーにとって十分なものに短縮する方法はありますか？しかし、どのようにして人気のあるTzを決定するのでしょうか。
Windowsのリストはかなり良いようですが、それがモデルになるのに良いリストかどうかはわかりません。 DSTはオプションなので、興味深いのですが、リストがこれほど短いのはなぜですか？誰か ここでtzの同等物を考え出した 。
私は太平洋夏時間（PDT）にいます。 JSのgetTimezoneOffset()は、420 ==>オフセット-7を返します。上記のタイムゾーンリストを使用する場合、US/Pacific（-8）をどのように確認できますか？
さらに、タイムゾーンの一般的な名前は何ですか？ US/PacificまたはCanada/Pacific確かに親しみやすいようですAmerica/Los_AngelesまたはAmerica/Vancouver。
最後に、上記の2つのタイムゾーンはどのように違うのですか？安全にグループ化して、America/Los_Angelesアプリ内？ 1つのタイムゾーンをどのようにまとめますか？
あなたが参照するリストには、大量の重複が含まれています。 Wikipediaのタイムゾーン のリストを見ると、40の異なるタイムゾーンが見つかります。 80％の解決策を求めていたので、リストを12（30または45分のオフセットがあるもの）でカットしても安全です。これにより、「のみ」28オプションが残ります。表示されたリストには多くの重複が含まれていますが、タイムゾーンを選択するUXについての質問が残っています...
それを行う1つの方法は、オフセットといくつかの都市の例の2つのタイムゾーンショートカットを作成することです。
download bmml source – Balsamiq Mockups で作成されたワイヤーフレーム
なぜこのようにですか？
名前について：
ユーザーはタイムゾーンの名前を知っていることがあります。 PDTまたはCET。しかし、MEZ（ドイツ語）のようなローカルフレーバーがあるか、これらの用語をまったく知らないユーザーを見つけるでしょう。標準はUTC（協定世界時）ですが、多くの人々はこれをまだGMT（グリニッジ標準時）として知っています。
例としての国と都市：
タイムゾーンの場所の例を使用することは良い考えです。国を使用することはより一般的であり、優れていますが、機能しません。米国のため。都市を使用した選択で一貫していることは、より良い方法です。
別のオプション：
開発能力がある場合は、入力フィールドを提供し、人々に都市または国の入力を依頼することができます。ユーザーが入力した内容に応じて、タイムゾーンを選択します（送信時、それが一意のヒットである場合のみ）またはユーザー入力に一致するタイムゾーンのサブセットを提案します：
ユースケースとアプリケーションによっては、別の方法があるかもしれません。とにかくユーザーが場所や住所を入力した場合最善の解決策は、ユーザーに手動で選択させるのではなく、この情報を事前に入力することです以前の入力に基づいてそれら。
「Where are you」というタイトルのマップ。ユーザーがゾーンを選択すると、現在の時刻（確認のため）のテキスト「現在地は08:15 AM」が表示されます。
getTimezoneOffset（）
最も簡単な解決策は、ログインやページが読み込まれるたびにgetTimezoneOffset（）を呼び出すことであり、ユーザーに負担をかけないようにする必要があります。なぜ効果がないのかわかりません。 getTimezoneOffset（）は、地理的位置とローカルのDSTプラクティスを正確に考慮していると思いました。 getTimezoneOffset（）がいつ、なぜ、どのくらいエラーを出すかを理解するために、これをさらに調査する必要があるかもしれません。
ゾーンのローカライズ
ユーザーにタイムゾーンのリストを表示する必要がある場合は、リストをフィルタリングし、IPアドレスまたはユーザーが指定した国名に基づいて、地域の名前を調整してみてください。これは、製品で行う必要があるより一般的なグローバリゼーション/ローカリゼーションの一部になります。
タイムゾーンではなく時間を使用
ユーザーにタイムゾーンを尋ねるのではなく、ローカルtimeを求め、getTimezoneOffset（）と比較して修正を計算する方が良いでしょう。 UTC。つまり、表示された時間= UTC + getTimezoneOffset（）+ user_supplied_correction。時間を15分以内で入力する方が、数十のタイムゾーンから選択するよりも簡単で、その多くは不慣れなものになると思います。 getTimezoneOffset（）を使用してデフォルトの時間を設定します。おそらくほとんどのユーザーは時間を入力する必要さえありません。あるいは、せいぜいわずかな変更を加えるだけです。
夏時間の慣行
ローカルのDSTプラクティスを取得することは困難です。ユーザーにDSTが変更される正確な日付を知っていると期待することはできません。また、DSTが1年の何時であるかをユーザーが知ることさえ信用できません。ただし、おそらくgetTimezoneOffset（）は、ローカルのDSTプラクティスを十分に正確に示します。これは、タイムゾーンよりも変動が小さいと思います。その場合、UTC + getTimezoneOffset（）+ user_supplied_correctionを使用することで処理されます。
GetTimezoneOffset（）がそのために正確でない場合は、場所をDSTプラクティスに関連付けるテーブルまたはサービスが必要です。繰り返しになりますが、ユーザーのIPアドレスを使用することも、ユーザーの国（および州/県）を使用することもできます。とにかく、その情報を要求していると仮定します。完璧ではありませんが、大多数のユーザーで機能する場合は問題ないかもしれません。ユーザーが時刻を修正する簡単な方法を提供した場合、少数のEdgeケースのユーザーは常にDSTを手動で調整するオプションを持っているので、ユーザーに間違った時刻で生活することを強制することはありません。
カレンダーイベント
上記は、現地時間を正しく表示することに関心があることを前提としています。別のタイムゾーンで発生する可能性のあるカレンダーイベントを入力する場合、ドロップダウンのタイムゾーンの名前は、イベントについてユーザーに知らせる情報ソースでタイムゾーンがユーザーにどのように表現されるかと一致する必要があります。たとえば、ユーザーが「ウェビナー午後2時の太平洋時間」のようなものを見たり聞いたりした場合、1つのオプションは「太平洋時間」です。それらの表現が何であるかを見つけるために、いくつかの調査を行う必要があります。おそらくユーザーの数によって異なります。オタクはUTC +/- Xを使用するかもしれませんが、おそらく他の誰も使用しません。パイロットが使用するソースは、場所に関係なくしばしばUTCを使用します（NOTAMなど）。地域によって、同じタイムゾーンの名前が異なる場合があります。
「太平洋標準時（3時間前）」のように、ユーザーの現地時間（UTCではない）からのオフセットを冗長に示すと役立つ場合があります。ユーザーはオフセットとは何かを知っている可能性があるため、これはユーザーが選択を確認するのに役立ちます。もちろん、ユーザーはオフセットを知っている場合に対応する現地時間を入力するオプションを常に持っている必要があります。また、タイムゾーンを特定するよりもオフセットを取得する方が簡単な場合もあります（たとえば、イベントが発生する場所にいる人に電話して、現地時間を尋ねます）。
ドロップダウンが5-15の最も一般的に使用されるタイムゾーン（おそらくユーザーのタイムゾーンに地理的に最も近いタイムゾーン）のみをリストし、ダイアログを開くか、タイムゾーンの詳細をリストするページを表示する[その他]オプションを含めることは意味があります（たとえば、地図で補足されます）。
間違った問題を解決しようとしている可能性があります。
ユーザーに適切なオプションを選択するか、少なくともリストをフィルタリングするか、オプションを削減または編集する前に、他の回答で提案されているように、JavaScriptまたはGeoIP検出を使用してこれを実行できるはずです。
この問題がWebサイトで解決されており、すべてのユーザーの現地時間でイベント時間を表示する場合、この解決策が好きかもしれません。ユーザーにタイムゾーンの入力を要求することはありません。代わりに、時間をUTCに保存し、データの表示に関してはローカル時間に自動的に変換します。
サーバー側でUTCオフセットを決定する方法がないため、この変換はクライアント側で実行する必要があります（オフセットealierを検出できなかった場合を除きます）。
また、Dateオブジェクトには、時間を自動的にローカルタイムゾーンに変換する優れた機能があります（C＃）。
JavaScriptSerializer serializer = new JavaScriptSerializer();
DateTime now = DateTime.Now;
DateTime utcNow = now.ToUniversalTime();
Console.WriteLine(now);
Console.WriteLine(utcNow);
Console.WriteLine(serializer.Serialize(utcNow));
出力：
17.05.2012 9:16:08
17.05.2012 5:16:08
"/Date(1337231768190)/"
ブラウザで：
alert(new Date(1337231768190));
出力：tc時間がローカル時間に変換される方法に注意してください
Thu May 17 2012 09:16:08 GMT+0400 (...)
1つのタイムゾーンに複数のオプションを設定します。 -8太平洋時間-8ロサンゼルスなど.
大都市とタイムゾーンに基づいてユーザーが選択できるようにします。
最もユーザーフレンドリーなアプローチは、ユーザーのタイムゾーンを決定することです。潜在的なユーザーが入力するフィールドが1つ少なくなります。
このプロジェクトを見てください： https://bitbucket.org/pellepim/jstimezonedetect
JavaScriptを使用してマシンのタイムゾーンを決定します。 'America/New_York'のような識別子を提供します。
ユーザーがアカウントを作成するときに、JavaScriptを介してタイムゾーンを取得し、保存します。ユーザーがウェブアプリを起動するたびに、タイムゾーンが変更された場合に備えてタイムゾーンを更新します。
JavaScriptを無効にしているユーザーをサポートする必要がある場合、状況は少し複雑になります。おそらく、それらのユーザーに対してのみタイムゾーンフィールドを表示します。
この質問をもう一度再検討して、Googleはかなり良い仕事をしたと思います。タイムゾーンは最初に国ごとに絞り込まれます。
クリックマップのアプローチは非常に良いですが、デバイスの種類を超えてレンダリングすることについては疑問に思います。より基本的な方法は、ユーザーに大陸、次に地域を尋ねることです。一対のHTML選択入力だけで本当に必要です。
大陸と地域のJSONエンコードされたリストは、私のCDN https://rack.pub/cdn/timezones.json で入手できます。動作しているUTCタイムスタンプジェネレーターが表示されます https://rack.pub/timestamp 。
{
"asia": {
"Afghanistan":"UTC+04:30",
"Armenia":"UTC+04:00",
...
