web-dev-qa-db-ja.com

ユーザーが希望する日付形式を有効にする

ユーザーに私のWebサイトでmm/dd/yyyy形式のみを使用することを強制したくありません。

私の場合:ユーザーは、Webサイトで希望する日付形式(カレンダー、表など)を選択できます。
2016年12月30日
2016年12月30日
2016年12月30日
2016年12月30日

ユーザーが入力できる日付入力形式に制限を設けたくありません(ユーザーが表示に使用する日付形式に関係なく)。したがって、すべての入力が有効になります
12302016
2016年12月30日
2016年12月30日
2016年12月30日
2016年12月30日
2016年12月30日
12月30日(自動的に現在の年が配置されます)

Q 1:
そのようなことをするのは良い習慣ですか(ユーザーに特定の日付形式のみを入力させるための合理的な制限はありません)。

Q 2:
ユーザーが次の入力に移動した後、日付形式をユーザーが設定したカスタム形式に置き換えるのは良い考えですか? (例:ユーザーは「30122016」と入力しますが、別のフィールドに移動すると、日付は2016年12月30日に置き換えられます)

製品は米国市場向けにのみ製造されています

7
ProgZi

必要に応じて、ユーザーが日付を表示するための独自の形式を選択できるようにしてもかまいません(結局のところ、この機能が不要な場合は、常にデフォルトのオプションを使用できます)。

ただし、日付を選択するには、常に同じGUIウィジェットを提示する必要があります。

1)カレンダー、または

2)日、月のフルネーム、4桁の年を含む3つのドロップダウンメニュー

これにより、選択した日付のあいまいさがすべてなくなります。その後、ユーザー定義の形式で日付を表示できます。

1
dr_

2つの問題が1つにまとめられているようです。

読みやすい日付の表示

クリソフが彼の答えで述べたように、他のものより理解するのが難しいいくつかの日付形式があります。あなたがすべきことは、最も一般的に使用される日付形式を選択し、これらをユーザーのオプションとして提示することです。

例えば.

  • 2016年1月1日(北米)
  • 2016年1月1日(ヨーロッパ)
  • 2016-01-01(アジア/その他)

月、日、年がユーザーが慣れ親しんだ方法で並べられている限り。スラッシュを使用するか、ダッシュやドットなどを使用するかはほとんど問題になりません。

簡単な日付入力を許可

最良の入力は、フォーマットにとらわれないものでなければなりません。ユーザーは任意の形式で日付を入力できます(たとえば、1月1日、01-01-2016、2016.1.1)。システムは、前のステップで選択した日付形式を理解してフォーマットする必要があります。

0
nightning

最も重要なのは、ユーザーが入力に成功したかどうかにかかわらず、ユーザーが明確なフィードバックを受け取ることです。

Mac用のZoteroデスクトップは、入力がどのように解釈されるかをユーザーに伝えることにより、これをうまく行います。ユーザーは形式を選択する必要がないことに注意してください。日付フィールドに値を入力するだけです。

Zoteroの例1

Zotero date input example 1

Zoteroの例2

Zotero date input example 2

Zoteroの例3

Zotero date input example 3

0
JeroenEijkhof

30 Dec 2016は明確で、理解可能で、すべての英語話者に受け入れられるため、通常、これを使用するときにカスタマイズ可能な日付表示形式を提供する必要はありません。 Dec 30, 2016は少し悪いです。

インターネットおよび英語のソフトウェア(多くの非ネイティブおよび旅行者のデフォルトおよびフォールバック言語であるため)では、2つの等しい区切り記号を持つすべて数値の3部構成のグレゴリオ暦の日付は、常にアイテムの厳密な順序、つまり大きいか小さいかのいずれかを使用します。エンディアン、決してミックス。セパレータは、一方のエンディアンを他方よりもわずかに優先する場合もあります。 big/small(URLパスを考える)とsmall.big. (だが big.float)。

米国の口語の順序を維持したい場合は、常に2つの異なる区切り文字(通常の2文字のサフィックスを含む)または口頭の月を使用します。年を2桁に短縮する必要がある場合は、前にアポストロフィを追加します。

禁止されている数値の日付表示形式

これらは本質的に壊れており、必要以上に読者に認知的負荷をかけます。

  • MMDDYYYY:12/30/201612.30.201612-30-2016
  • YYYYDDMM:2016/30/122016.30.122016-30-12
  • DDMMYY:30/12/1630.12.1630-12-16
  • MMDDYY:12/30/1612.30.1612-30-16
  • YYMMDD:16/12/3016.12.3016-12-30
  • YYDDMM:16/30/1216.30.1216-30-12

(ハイライトされた最も悪いもの)

推奨されない数値の日付表示形式

これらは本質的には問題ありませんが、禁止されたフォーマットが急増しているため、適切なコンテキストがないとあいまいになる可能性があります。

  • DDMMYYYY:30/12/201630.12.201630-12-2016
  • DDMMYY:30/12/’1630.12.’1630-12-’16
  • YYMMDD:’16/12/30’16.12.30’16-12-30
  • MMDDYYYY:12/30, 2016
  • MMDD:12/30-12-30
  • DDMM:30.12.
  • YYYYMM:2016/122016-12(YY <12の場合、どちらも年の範囲と誤解される可能性があります)
  • MMYYYY:12/201612, 2016

許容される数値の日付表示形式

  • YYYYMMDD:2016/12/302016-12-302016.12.30

ご覧のように、受け入れ可能なすべての数値形式は、ターゲットグループがよく知っているものではないため、使用しないでください。

フリーテキストの日付入力は、明確な値(禁止された形式や曜日が重複しているように見えるものを含む)を認識する必要がありますが、ユーザーに優先形式と有効な日付範囲についても通知する場合があります(解釈の選択にも役立つ場合があります)。 。解析結果を検証するためにユーザーに即座にフィードバックを提供し、特に不確実性があった場合は、ユーザーがいつでもデータを修正する手段を提供する必要があります。

0
Crissov