世界中の誰でも理解できる普遍的な日付形式はありますか？

カナダでは、誰もが日付形式に精通していますYYYY-MM-DD。ヨーロッパや南アフリカでは、彼らが好むDD-MM-YYYY。南アフリカから、YYYY-MM-DD日付の形式に戸惑うユーザーがいます。この状況に対処する方法はありますか？

私は次のメソッド形式をすべてに使用することを考えていました： Feb 02, 2011

曖昧部分は、それらが数字で表さている場合、月から日を区別することです。

02/03は2月3日または3月2日を意味しますか？

月の識別子をその名前の番号から変更することで、あいまいさを解消できます。あなたの質問に答えるために、あなたのバリアントはFeb 02, 2011良い解決策のようです。

2桁のみで年を書いている場合でも、年の数字には潜在的な問題がありますが、修正は簡単です（4を使用）。

いいえ 。普遍的に認識されている日付形式はありません。

ISO 8601は、日付形式の国際標準を定義しています。そのため、おそらくこれが最善の妥協案です。しかし、あなたが言うように、ユーザーは常にこのフォーマットを好むわけではありません。

唯一の正しい解決策は、国ごとに異なるフォーマットを提示することです。選択したプログラミング言語に重要なファンがいる場合、これを実現するための標準ライブラリがあることに気付くでしょう。

そのためにカルチャー情報を使用する必要があります。または、少なくともローカルの表示形式。

JavaScriptでは、Dateクラスに toLocaleStringメソッドを使用できます。

C＃の場合、ToStringを使用するときにフォーマット文字列を使用できます。

Googleをすばやく検索すると、選択した言語で文化を使用する方法が表示されます。

YYYY-MM-DDを使用します（常に4桁の年と2桁の月と日を書きます）。私の知る限り、YYYY-DD-MMはめったにありません。そのため、YYYY-MM-DD形式は、あいまいさが最も少ない形式であり、最終的にユーザーが理解するようになります。また、簡単なソートの利点も得られます。

各ユーザーに自分のロケールを与えることができます。ロケールは、ローカルの設定に従って日付やその他の情報をレンダリングしますか？

多くの場合、ほとんどのフレームワークでロケールを設定し、I18nを使用できます。

一般的なケースでは、フォーマットと値の両方を指定する必要があります。これは、ありとあらゆる混乱を避ける唯一の方法です。たとえば、「2011-02-02（YYYY-MM-DD）」と発声できます。ただし、シンプルさと読みやすさを犠牲にして提供されるため、読者を知っておいてください。

もちろん、「今後、すべての日付はYYYY-MM-DD ....の形式になります」と言うことができます。そうすると、後で表示される「2011-02-02」が明確になります。それはもっと口当たりが良いかもしれませんが、繰り返しますが、あなたの聴衆を知っています。

この提案はおそらく役に立たないでしょうが、ローマ数字で書かれた月を見てきました。確かに、2011年3月11日は11月11日か3月3日かもしれませんが、最初の解釈のほうが自然だと思います。

それはあなたが何をしているのか、入力をどの程度制御できるのか、そしてどこかに保存しているのかに依存すると思いますか？

ストレージには、Mike Dunlaveyが提案したものを使用します。

YYYYMMDDHHMMSSの時間はUTCですが、あなたが与える理由により、私が選択できるときはいつでも私が行く方法です。選択肢がない場合は、ユーザーに選択させます。

彼はこれを答えとして残さなかったので、私は残します。

もう1つ：CCの有効期限を入力する方法の次のスクリーンショットを確認してください：http : //www.ubercart.org/files/credit_card_checkout.jpg

この例の素晴らしい点は、それがあなたを考えさせないことです。月の番号と名前の両方を使用します。入力に同様のものを使用することを検討します。月には、番号とローカライズされた名前の両方を含めます。年と日の場合は、数値のアップ/ダウンまたはコンボボックスを使用します。次に、カレンダーコントロールも気の利いたようです。

私が言ったように、それは依存します。ストレージの場合：データベースを使用している場合は、データベースが明確で明確なデータ形式を提供しているかどうかを確認します。他の方法を使用している場合は、「時がUTCであるYYYYMMDDHHMMSS」が役立つかどうかを確認してください。それをユーザーに提示するには、どの国やロケールが関係している可能性があるかを考慮して、最もわかりやすい「私に考えさせない」種類の表現を選びます。オプションの提供も検討してください。

最後に、すでに似たようなことをしているいくつかのクールな製品をチェックして、それらがどのようにそれを行うかを調べてみてください。

Webサイトのエンドユーザーに共通の日付と時刻の形式はありません。値はクライアントのタイムゾーンごとに異なるため、単一の日付時刻値もありません。グローバリゼーションを使用する必要があります。ユーザーの文化に基づいたデータ、時間、通貨、カレンダー、ナブマー形式のターゲティングです（ユーザーのブラウザーから渡された承認済み言語から、またはアプリケーションに直接実装されたスイッチによって受信できます）。一部のAPI（.NETなど）は、この機能を直接サポートしています。

日付と時刻をデータベースに保存するには、ユニバーサル形式のUTC（協定世界時）を使用します。

国際コンピューティングの世界のすべてのインテリジェンスがこのナットを解読できないことは残念です。

マイクロソフトや他のベンダーは、日と同じように月をゼロで埋めるように日付マスクを追加することを検討していませんが、3桁です。慣習を採用することで、数学的に同等の新しい一連の変更された日付形式を促進し、従来の日付レイアウトで簡単に識別および区別できるようになります。あれは：

• 0MM-DD-YYYY（例：2016年2月3日は002-03-2016）

• DD-0MM-YYYY、たとえば03-Feb-2016の場合は03-002-2016

• YYYY-0MM-DD（例：2016-02-03の場合は2016-002-03）

• YYYY-DD-0MM、例：2016-03-002（誰かが使用したい場合！）

この方法で修正するのは簡単すぎるようです...シンプルなだけではうまく売れないと思います。