8

(これは、UIを実行するために必要なテクノロジーではなく、UIに関する質問です)

さまざまなタイムゾーンで発生するイベントの時間をユーザーに表示する最も明確な方法は何ですか?「平均的な」ユーザーはUTCとタイムゾーンを理解していますか?

現地時間とUTCオフセットをキャプチャし、さまざまなタイムゾーンで発生するイベントのデータベース(SQL 2008 DateTimeOffset)に保存します。また、ユーザーはさまざまなタイムゾーンにいます。

評価できるように、以下にいくつかの回答を提案しますが、別の提案をいただければ幸いです。

編集:ユーザーのタイムゾーンに時間を表示しないようにしたいです。異なるタイムゾーンのユーザーは同じイベントについて話し合うことになり、異なるタイムゾーンにローカルである場合は混乱が生じます。

編集:私は質問を一般的で、うまくいけばより多くの人々に役立つようにしたかったのですが、特定のコンテキストでは、これは小包を追跡するためのWebアプリケーションです(FedExを考えてください)。区画はタイムゾーンを越えます。カスタマーサポートは英国にありますが、受信者は他の場所にいる可能性があります。

4

13 に答える 13

4

「ニューヨーク」、「ロンドン」、「東京」、「パプア、ニューギニア」というラベルの付いた時計がある、または特定の視聴者がいる場所ならどこでも、古いスタイルのニュースルームのグラフィックを試してください。クロックをアナログまたはデジタル、またはその両方にすることができます。

これで混乱する人はいないでしょうが、ほとんどの人は GMT+7 (またはその他) が何を意味するのかを本当に知っているとは思いません。

于 2008-11-08T17:49:36.320 に答える
3

15:18 GMT+1のように現地時間とオフセットを表示します

于 2008-11-08T15:24:54.210 に答える
2

タイムゾーンの略称で表示する

それ以外の

15:18 GMT+1

中央ヨーロッパ時間で表示

15:18 CET 

人々は自分のタイムゾーンを見ることに慣れています

于 2008-11-08T15:32:08.437 に答える
2

戦略は、UI の時間 (ユーザーに表示または入力するとき) がユーザー自身のタイムゾーンになるようにする必要があります。

一方、アプリケーション、つまり Ruby コードとデータベースでは、時刻は常に UTC タイムゾーンで保持されます。

あなたの仕事は、ユーザーがタイムゾーンを選択できるようにし、必要に応じてこのタイムゾーンと UTC タイムゾーンを相互に変換できるようにすることです。

この記事では、Rails 環境でこれを行う方法を説明します。

これは、ユーザーのタイムゾーンを取得できるか、そのタイムゾーンを「ユーザー」テーブルに保存できることを意味します。

于 2008-11-08T15:40:57.657 に答える
2

あなたはパッケージについて言及しています。ロジスティクスでは常に現地時間を表示するのが慣習であり、これは UPS などが追跡データのステータス履歴に表示するものです。

その localtime が現在のユーザーのタイム ゾーンでない場合は、時間にタイム ゾーンの注釈を付けることを検討します (例: 09:00 (Europe/Amsterdam) )

場所の名前は、あいまいになる可能性がある略語よりも優れていることに注意してください。時刻がどこにあるのか、またはユーザーのタイム ゾーンとの違いをユーザーに伝える方が便利かどうかは、あなた次第です。

この問題を回避する 1 つの方法は、4 時間前などの相対的な時間を使用することです。

于 2009-01-08T01:57:08.410 に答える
1

これは、特定のアプリケーションがなければ決定的に答えることはできないと思います。たとえば、同じタイムゾーンのすべてのユーザーのイントラネット アプリケーションでは、多くの場合、タイムゾーンを完全に省略できます。株式市場のアプリケーションの場合、市場のタイムゾーンを基準にして時刻を作成したい場合があります。ソーシャル Web アプリケーションの場合、ユーザーのタイムゾーンを基準にして時刻を設定したい場合があります。適用される一般原則は次のとおりだと思います。

  1. 混乱の可能性がある場合は、常にタイムゾーンを指定する必要があります
  2. ユーザーと協力して、時間をどのように表示したいかを確認する必要があります。
于 2008-11-08T15:52:00.253 に答える
1

他の人が述べたように、アプリケーションが特定またはローカルである場合、タイムゾーンを省略したり、他の仮定を行ったりできると思います。

グローバルの場合は、データを一貫して (常に UTC) 保存してから、表示用に変換します。さらに、ユーザーに自分のタイムゾーンを指定させ、場合によっては日付と時刻のフォーマットも指定させたいと思うでしょう。いくつかの静的オプションを指定するか、フォーマット文字列を指定する完全な機能を指定するかのいずれかです。

ユーザーにオプションを提供したくない場合は、単純な HH:MM TZ または HH:MM GMT+/-H で十分でしょうか? または、サーバーのローカル時刻を表示して、脚注または FAQ に「すべての時刻は PST」などと表示することもできます。

ユーザーとして、私は最大限の構成可能性を好みますが、プログラマーである私は偏見があると思います。

于 2008-11-08T15:59:21.737 に答える
1

私は GMT+offset が好きです (offset が「通常」ユーザーのタイムゾーンであると仮定します)。追加の手がかりとして、そのタイム ゾーンのいくつかの都市を一覧表示するツールチップ (半球ごとに 1 つ)、またはタイム ゾーンをより詳細に説明するページへのハイパーリンクを提供します。

于 2008-11-08T16:08:43.497 に答える
1

あなたが説明したのは、ページの閲覧者が顧客をサポートしている状況です。

ですから、顧客の視点に焦点を当てたデザインをお勧めします。したがって、デフォルトまたは主要な表示方法は、顧客の現地時間にする必要があります。電子メールまたは IM を使用している場合は、ソースとしてある種のユーザー ディレクトリが必要です。電話を使用している場合は、発信者 ID を時間換算の基準にすることができます。

これは、ソフトウェアがサポート サービス全体ではなく、一部にすぎないことを示す例でもあります。ディスプレイは他のタイムゾーンに簡単に切り替えることができる必要があり、電話担当者は、時間ベースの情報を提供する前に、現在のタイムゾーンを尋ねるように常にトレーニングする必要があります。

また、到着時に現地時間を表示するオプションも必要です。これにより、シームレスかつ効率的な方法で顧客と会話できます。

CU: "When will it arrive?" 
CS: "Based on your phone number, I am assuming you are in EST. The ETA is 8pm". 
CU: "I am traveling in Chicago right now. Can you tell me when I should check back?"
(Phone rep taps a "CST" button on the screen, and the displays convert.) 
CS: "Sir, if the package does not arrive before 9:10pm, your local time, please call us."
于 2008-11-29T07:06:15.403 に答える
0

これは非常に状況依存の状況です。postos と tvanfosson の提案に基づいて構築したいと思います。都市や国の名前は、人々が現地時間を設定するのを助けたり、目的の現地時間しか知らないときに他の場所の時間を設定するためのダイアログで使用したりする場合を除き、必要ないと思います (圧倒されたり気を散らしたりしないという大きな課題)混乱しているユーザー)。

場所が時間に関連付けられている場合、その場所の日時が適切であることがよくあります (たとえば、市場の閉鎖、イベント、旅行の到着と出発などについて話す場合)。ツールチップを使用して、(1) gmt と (2) インターフェースを見ているユーザーの見かけの現地時間に変換できるという考えを私は支持します。オフセットも役に立ちます。また、真夜中の交差点が含まれる日付も役立ちます。

また、現地時間ではない可能性があることを示す手がかりとして、タイムゾーンを明示する必要があることにも同意します。さらに、タイムゾーンなしで現地時間が表示されている場合でも、ツールチップは重要だと思います。(特に、ラップトップを持って旅行する人がホームベースのタイムゾーン設定を維持する場合があります。)

細部への特別な注意: 夏時間、夏時間などの時間シフト、および場所間の違い (すべての場所に夏時間があるわけではなく、すべての場所が同時に変更されるわけではありません) および時点間の違い (に特に未来)。

于 2008-11-08T18:04:32.500 に答える
0

最善の方法は、すべての日付/時刻情報を UTC で保存してから、ユーザーの時刻にオフセットした時刻を表示することです。.NET には、これに対するあらゆる種類のサポートがあります。他のほとんどの環境でも同様です。ロンドンで午前 7 時にデータを入力すると、午前 1 時または午前 2 時 (EDT) と表示されます。UTC の最大の利点は、夏時間がない場所にいるときに、夏時間や夏時間の欠如など、厄介なことをすべて回避できることです。韓国、インド対北米の新しいオフセット。

私は 15:30 EDT などの 24 時間制が好きですが、12 時間モードで動作するものもあると確信しています。それを確実にオプションにします。

于 2008-11-08T18:05:44.913 に答える
0

「小さな」アプリケーションが突然全国的 (米国では 5 つまたは 6 つのタイムゾーン) またはグローバルになることに何年にもわたって何度か噛まれてきたので、可能であれば常に日時データを UTC で保存しています。

他の多くの投稿が指摘しているように、問題は表示になります。

日付/時刻が表示され、それが現在のユーザーの場所 (およびロケール) に関連している場合は、ユーザーの現地時間で表示します。

複数の日付/時刻が表示され、それらが異なる場所 (おそらく異なるロケール) に関連している場合、ユーザーはその場所のタイムゾーンで表示される時刻を 12 時間形式で表示することを好むことがわかりました。

航空券がどのように印刷されるか (少なくとも米国では) を考えてみてください。出発時刻と到着時刻は、出発都市と到着都市のタイムゾーンで表示されます。最適な旅程には、「総移動時間」または期間も表示されます。

では、ロケール形式のデータをユーザーに表示したいと思います。ロケールはどのように決定しますか? Web アプリケーションの場合、ロケールはほとんどの HTTP ヘッダーに存在しますが、ユーザーのマシンでロケールが正しく設定されていることを常に信頼できるとは限りません。そのため、ほとんどの場合、ロケールを特定できるデータ (郵便番号、都市、州、国など) を含むプロファイルを設定するか、場所を特定できる情報を入力するようユーザーに求めることになります。ユーザーが実際に存在する (Web アプリまたは「ネイティブ」アプリケーションの場合)

IP アドレスによるジオロケーションが広く利用可能になったので、これを実装する必要はありませんでしたが、それも必ずしも正確ではありません。

これらのアプリケーションで作業したとき、個人設定はほとんど常に 24 時間形式、UTC、ISO8601 になることに注意してください。これにより、ユーザーがどこにいるかに関係なく、何時が表示されているかがわかります。

于 2008-11-08T20:03:38.407 に答える
-2

常にUTCで時刻を表示します

NB私はこれに同意しません。投票のオプションとして追加しました。

于 2008-11-08T15:25:08.717 に答える