特定の言語であいまいな日付文字列を処理するための最良の方法は何でしょうか。ユーザー入力の事前検証がオプションではない場合、MM / dd / YYYYの日付をどのように解析する必要がありますか?
次のあいまいな日付をどのように解析し、どのような理由(統計的、文化的など)で解析しますか?
1900年1月11日[ M/dd/YYYY ]または1900年11月1日[ MM/d / YYYY ]としての「1111900」?
特定の言語であいまいな日付文字列を処理するための最良の方法は何でしょうか。ユーザー入力の事前検証がオプションではない場合、MM / dd / YYYYの日付をどのように解析する必要がありますか?
次のあいまいな日付をどのように解析し、どのような理由(統計的、文化的など)で解析しますか?
1900年1月11日[ M/dd/YYYY ]または1900年11月1日[ MM/d / YYYY ]としての「1111900」?
形式が由来する言語/文化を正確に把握していない限り、共通の日付形式を確立する必要があります。
私がお勧めするロケール中立の日付形式と呼ばれるものがあります。(YYYY-MM-DD)
それを使用するか、年、月、日がどの部分であるかを明確にするかのいずれかです。(DD MON YYYY または 2003 年 4 月 22 日)
参照:日付形式に関するw3 の見解。
編集:ロケールに依存しない日付形式の入力ミス
ソフトウェアの重要度にもよりますが、あいまいな日付入力は無効な入力として扱います。取得する日付入力が適切で曖昧でない形式であることを (ソースで) 確認する必要があります。それでも「1111900」のような値が得られる場合は、入力が正しくありません。誰かが何らかの方法で有効性チェック コードをバイパスしたことは明らかであり、おそらく最も正しい方法はデータを破棄することです。
もちろん、これがオプションではなく、日付スポットを取得することが重要でない場合は、いつでも推測できますが、推測になります. ただし、可能であればこれは絶対に避けます。サニタイズされていない入力を受け入れることは、一般的に最善の考えではありません。
このようなシステムで 1 月 11 日と 11 月 1 日の違いを知る唯一の方法は、コンテキストを確認することです。それ以外の場合は、ある種のあいまいさを解消する必要があります。その特定の日付形式は、病理学的に破壊的な圧縮の完璧な例です。
日付が重要な場合の私の好みは、オファーのドロップダウンまたはカレンダーを使用して、常に期待どおりの形式になるようにすることです。