これは私が何度か遭遇した問題です。データベーステーブルに保存するレコードがあるとします。このテーブルには、「date_created」というDateTime列があります。この特定のレコードはかなり前に作成されたものであり、正確な日付は確かではありませんが、年と月はわかっています。あなたが年だけ知っている他の記録。日、月、年を知っているその他の記録。

「1978年5月」は有効な日付ではないため、DateTimeフィールドは使用できません。複数の列に分割すると、クエリを実行できなくなります。他の誰かがこれに遭遇しましたか？もしそうなら、どのようにそれを処理しましたか？

私が構築しているシステムを明確にするために、それはアーカイブを追跡するシステムです。かなり前に作成されたコンテンツもありますが、知っているのは「1978年5月」だけです。1978年5月1日として保存することもできますが、この日付が月に対してのみ正確であることを示す何らかの方法があります。その方法で、数年後、そのアーカイブを取得するときに、日付が一致しない場合でも混乱しません。

私の目的では、「1978年5月の不明な日」と「1978年5月1日」を区別することが重要です。また、ほとんどのデータベースシステムでは無効な日付値として拒否されるため、「1978年5月0日」のように不明な値を0として保存したくないでしょう。

データベースの通常のDATEフィールドにすべての日付を保存し、DATEフィールドが実際にどれくらい正確かを追加の精度フィールドに追加します。

date_created DATE,
date_created_accuracy INTEGER, 

date_created_accuracy：1 =正確な日付、2 =月、3 =年。

日付があいまいな場合（1980年5月など）は、期間の開始（1980年5月1日など）に保存します。または、日付が年（1980年など）に正確な場合は、1月1日として保存します。1980年、対応する精度値。

この方法では、ある程度自然な方法で簡単にクエリを実行でき、日付がどれほど正確であるかという概念があります。たとえば、これにより、との間の日付を照会Jan 1st 1980しFeb 28th 1981、あいまいな日付1980とを取得できますMay 1980。

この種のデータを通常の日時情報として使用する必要がない場合は、任意の単純な文字列形式を使用できます。

ただし、すべての機能を保持する必要がある場合は、考えられる次の2つの回避策があります。どちらもデータベースに追加情報を保存する必要があります。

1. 作成min dateおよびmax dateフィールド。「不完全な」データの値は異なりますが、正確な日付では一致します。
2. 不正確な日付の種類ごとにタイプを作成します（none _ 0、date_missing _ 1、month_missing _ 2、year_missing_4など_を組み合わせて使用​​できます）。typeレコードにフィールドを追加し、不足している情報を保持します。

これは本当に技術的な問題というよりも要件の定義です。「過去の日付をどのように定義できるか」に焦点を合わせる必要があり、技術的な解決策が流れます。

私がこのような何かにアプローチしなければならなかったとき、私たちは通常：

• 物事のマッピング方法を定義します。MichaelTが示唆するように、月/日として定義されているものはすべて、その月の1日の午前0時に定義されるようにします。これは通常、ほとんどの目的に十分です-正確な日付がそれほど重要だった場合、おそらく35年後の記録がありますよね？
• これを追跡する必要があるかどうかを判断します-IE、わずかに作成された日付を持つレコードには、そう言うフラグが必要ですか？または、単にユーザートレーニングの問題であるため、人々はそれに応じて行動できます。

場合によっては、日付をファジーにするなどの処理が必要になることがあります。たとえば、1978年5月のクエリに対する応答が必要になる場合があります。これは実行可能です。create_date2フィールドを作成すると、古いレコードは30になります必要に応じて広がる日、新しいものは2つの同一の値を取得します。

日付が正確かどうかを示す最も簡単な方法は、デフォルトのNULLで正確度フィールドINT（1）を作成することです

日付が正確な場合、「date_created」に日付と時刻を格納し、NULLのままにします

日付が月に対して正確である場合、日付と時刻を月の1日として保存し、精度の値を1にします。

日付が1年1月1日のストアの正確な値2で正確である場合

異なる数値を使用して、第1四半期などの異なる値を保持できます。

過去に、正確な日付を開始日と終了日として保存しました。2012年5月21日は、start = 12 am,may21,2012およびend = 12 am,may22,2012として表されます。2012年は、start = 12 am,Jan1,2012 end = 12 am,Jan1,2013として表されます。

このアプローチを推奨するかどうかはわかりません。ユーザーに情報を表示する場合、2つの特定度の高いエンドポイントではなく「5月25日」を表示するために、日付範囲が1日を正確にカバーすることを適切に検出する必要があります（夏時間などを処理することを意味します）。

ただし、人間に翻訳しようとしない場合、エンドポイントを使用したプログラミングは、center + accuracyを使用するよりもはるかに簡単です。あなたは多くの場合に終わることはありません。それはかなりいいです。

なぜ2つの日付を保存しないのですか。

Created_AfterおよびCreated_Before。「上または後に作成される」および「上または前に作成される」実際のセマンティクス

したがって、正確な日付がわかっている場合、Created_AfterとCreated_Beforeは同じ日付になります。

2000年5月の最初の週であることがわかっている場合、Created_After = '2000-05-01'およびCreated_Before = '2000-05-07'です。

1999年5月を知っている場合、値は「1999-05-01」と「1999-05-30」になります。

「42年の夏」の場合、値は「1942-06-01」および「1942-08-31」になります。

このスキーマは、通常のSQLで簡単に照会でき、技術に詳しくないユーザーでも簡単にフォローできます。

たとえば、2001年5月に作成された可能性のあるすべてのドキュメントを検索するには：

SELECT * FROM DOCTAB WHERE Created_After < '2001-05-31' And Created_Before > 2001-05-01;

逆に、2001年5月に間違いなく作成されたすべてのドキュメントを見つけるには：

SELECT * FROM DOCTAB WHERE Created_After > '2001-05-01' And Created_Before < 2001-05-31;

ISO 8601の日付時刻形式には、期間の定義が含まれます。たとえば、

2012-01-01P1M （読み取り：2012年1月1日、期間：1か月）は、「2012年1月」である必要があります。

これを使用してデータを保存します。そのためには、String型のデータベースフィールドが必要になる場合があります。それについて賢明な検索を行う方法は別のトピックです。

一般に、わずかに正確性が低くても、一般的なクエリビジネスの日付はまだ可能であるため、それらを保存します。

過去の精度を知ることが重要な場合は、精度の「ウィンドウ」を+/- 10進数またはルックアップ（日、月、年など）として保存します。他のケースでは、ウィンドウの代わりに、元の日付値を文字列として保存し、可能な場合は1978-05-01 00:00:00および "1978年5月"などの日付時刻に変換します。

複数の列に分割すると、クエリを実行できなくなります。

誰が言ったのですか？あなたがすることは次のとおりです。

1. 日、月、年、それぞれint型の3つの列、およびDateTime型の4番目の列TheDateがあります。
2. TheDateがnullのままで、1つ以上のDay、Month、Yearフィールドに値がある場合、3列のDay、Month、Yearを使用してTheDateを構築するトリガーを使用します。
3. TheDateが提供されているが、これらのフィールドが提供されていない場合、Day、Month、Yearフィールドに入力するトリガーを使用します。

そのため、次のような挿入を行うと、 insert into thistable (Day, Month, Year) values (-1, 2, 2012);TheDateは2013年2月1日になりますが、Dayフィールドの-1により、2012年2月の実際の日付は不明です。

私の場合insert into thistable (TheDate) values ('2/5/2012');、日は5、月は2、年は2012になり、どれも-1でないため、これが正確な日付であることがわかります。

挿入/更新トリガーにより、3つのフィールド（Day、Month、Year）が常にクエリ可能なTheDateのDateTime値を生成するため、クエリの機能を失うことはありません。

別のオプションは、日付をフォームの整数として保存することですYYYYMMDD。

• あなたは年が1951年だけであることを知っている：として保存 19510000
• 月と年は1951年3月であることがわかります。 19510300
• 完全な日付は1951年3月14日です。 19510314
• 完全に未知の日付：として保存 0

利点

他の多くの回答が示唆するように、2つの日付フィールドまたは日付と精度の代わりに、1つのフィールドにファジー日付を保存できます。

クエリはまだ簡単です：

• 1951年のすべての記録- SELECT * FROM table WHERE thedate>=19510000 and thedate<19520000
• 1951年3月のすべての記録- SELECT * FROM table where thedate>=19510300 and thedate<19510400
• 1951年3月14日のすべての記録- SELECT * FROM table where thedate=19510314

ノート

• GUIにはGetDateString(int fuzzyDate)、実装が非常に簡単なが必要です。
• 並べ替えはint形式で簡単です。未知の日付が最初に来ることを知っておく必要があります。あなたは使用してこれを逆転できる99「パディング」のための代わりの00月または日のために。

ISO 8601は、「ファジー日付」の構文も指定しています。2012年2月12日午後3時は「2012-02-12T15」となり、2012年2月は単に「2012-02」となります。これは、標準の辞書式ソートを使用してうまく拡張されます。

$ (echo "2013-03"; echo "2013-03"; echo "2012-02-12T15"; echo "2012-02"; echo "2011") | sort
2011
2012
2012-02
2012-02-12T15
2013-03

これについての私の見解は次のとおりです。

ファジー日付からdatetimeオブジェクト（データベースに収まる）に移動します

import datetime
import iso8601

def fuzzy_to_datetime(fuzzy):
    flen = len(fuzzy)
    if flen == 4 and fuzzy.isdigit():
        dt = datetime.datetime(year=int(fuzzy), month=1, day=1, microsecond=111111)

    elif flen == 7:
        y, m = fuzzy.split('-')
        dt = datetime.datetime(year=int(y), month=int(m), day=1, microsecond=222222)

    elif flen == 10:
        y, m, d = fuzzy.split('-')
        dt = datetime.datetime(year=int(y), month=int(m), day=int(d), microsecond=333333)

    elif flen >= 19:
        dt = iso8601.parse_date(fuzzy)

    else:
        raise ValueError("Unable to parse fuzzy date: %s" % fuzzy)

    return dt

そして、datetimeオブジェクトを取得し、あいまいな日付に戻す関数。

def datetime_to_fuzzy(dt):
    ms = str(dt.microsecond)
    flag1 = ms == '111111'
    flag2 = ms == '222222'
    flag3 = ms == '333333'

    is_first = dt.day == 1
    is_jan1 = dt.month == 1 and is_first

    if flag1 and is_jan1:
        return str(dt.year)

    if flag2 and is_first:
        return dt.strftime("%Y-%m")

    if flag3:
        return dt.strftime("%Y-%m-%d")

    return dt.isoformat()

そして、単体テスト。ケースを見逃しましたか？

if __name__ == '__main__':
    assert fuzzy_to_datetime('2001').isoformat() == '2001-01-01T00:00:00.111111'
    assert fuzzy_to_datetime('1981-05').isoformat() == '1981-05-01T00:00:00.222222'
    assert fuzzy_to_datetime('2012-02-04').isoformat() == '2012-02-04T00:00:00.333333'
    assert fuzzy_to_datetime('2010-11-11T03:12:03Z').isoformat() == '2010-11-11T03:12:03+00:00'

    exact = datetime.datetime(year=2001, month=1, day=1, microsecond=231)
    assert datetime_to_fuzzy(exact) == exact.isoformat()

    assert datetime_to_fuzzy(datetime.datetime(year=2001, month=1, day=1, microsecond=111111)) == '2001'
    assert datetime_to_fuzzy(datetime.datetime(year=2001, month=3, day=1, microsecond=222222)) == '2001-03'
    assert datetime_to_fuzzy(datetime.datetime(year=2001, month=6, day=6, microsecond=333333)) == '2001-06-06'

    assert datetime_to_fuzzy(fuzzy_to_datetime('2002')) == '2002'
    assert datetime_to_fuzzy(fuzzy_to_datetime('2002-05')) == '2002-05'
    assert datetime_to_fuzzy(fuzzy_to_datetime('2002-02-13')) == '2002-02-13'
    assert datetime_to_fuzzy(fuzzy_to_datetime('2010-11-11T03:12:03.293856+00:00')) == '2010-11-11T03:12:03.293856+00:00'

2001-01-01T00:00:00.333333システムで正確に発生したが、システムが「2001」であると解釈するイベントがありますが、それは非常に起こりにくいようです。

私は、物事の正確な日付を取得できないことが多い多くの古い本を扱う出版社で働いています。私たちは通常、指定した日付のエントリ、日付と用の2つのフィールドを持つ年頃のブール：

date date
dateCirca enum('Y', 'N')

日付フィールドを使用して、イベントの日付、または真の日付がわからない場合は「十分近い」日付を示します。真の日付がわからない場合は、dateCircaフィールドにYマークを付けて、「1日」としてマークされている十分に近い日付を指定します。

1st March, 2013  // We don't know the day of the month
1st January, 2013  // We don't know the month/day of the year
1st January, 2000  // We don't know the month/day/year, we only know the century

概要

あいまいな日付時刻（または単にあいまいな日付）を格納するための多くの可能な表現、したがってデータベーススキーマがあります。

1. 日時とその精度または正確さを示すコード
2. 間隔を表すいくつかの可能性がある日時と間隔：
   1. すべての間隔を、日、分、ナノ秒などの固定単位の整数（または他の数値）量として表します。
   2. 間隔を整数（または他の数値）量とその単位を示すコードの両方として表します。
3. 開始日時と終了日時
4. ひも
5. 確率分布：
   1. 特定のファミリの特定の分布を指定するパラメーターの10進数または浮動小数点の数量。たとえば、正規分布の平均および標準偏差。
   2. 確率分布関数。たとえば、（ルックアップ）コード（特定の値のパラメーターを含む可能性がある）、または十分に表現力のある言語、形式、または表現での表現として。

[1]、[2]、および[3]はすべて（暗黙的に）均一な間隔、つまり（同じ）可能な時点のセットです。

[4]は最も表現力があります。つまり、可能な（または少なくとも任意の長さの）書かれた言語の文またはフレーズを許可する場合です。しかし、それは作業するのが最も難しいことでもあります。制限では、任意の値を処理するには人間レベルのAIが必要になります。実際には、可能な値の範囲を厳しく制限する必要があり、代替の「構造化された」値はおそらく、ソート、検索などの多くの操作に適しています。

[5]は、おそらく（やや）実用的な最も一般的なコンパクトな表現です。

等間隔

均一間隔は、（可能な）日付/時刻値のセットを表す最も単純なコンパクトな方法です。

[1]の場合、日付時刻値の部分は無視されます。つまり、指定された精度または精度よりも細かい単位に対応する部分は無視されます。それ以外の場合、これは[2]と同等であり、精度/精度コードは同じ単位（および暗黙の量1）の間隔と同等です。

[2]と[3]は表現的に同等です。[1]は、[1]で表現できない有効な間隔があるため、どちらよりも厳密に表現力が劣ります。日付の境界にまたがる12時間間隔に相当するファジー日時。

[1]は、ユーザーが他のどの表現よりも入力しやすく、通常は（少なくともわずかに）入力を少なくする必要があります。「2013」、「2014-3」、「2015-5-2」、「7/30/2016 11p」、「2016-07-31 18:15」など、日付をさまざまなテキスト表現で入力できる場合、精度または精度も入力から自動的に推測できます。

[1]の精度または精度は、ユーザーに伝達するフォームに変換するのが最も簡単です。たとえば、「2015-5月」から「2015年5月」を「2015年5月13日2p、プラスまたはマイナス13.5日」 （後者はとにかく[1]で表すことができないことに注意してください）。

ひも

実際には、クエリ、並べ替え、または複数の値を比較するために、文字列値を他の表現に変換する必要があります。したがって、書かれた自然（人間）言語は、[1]、[2]、[3]、または[5]よりも厳密に表現力がありますが、標準のテキスト表現または形式をはるかに超える処理方法はまだありません。それを考えると、これはおそらくそれ自体では最も有用な表現ではありません。

この表現の利点の1つは、実際には値がそのままユーザーに提示可能であり、変換を容易に理解できる必要がないことです。

確率分布

確率分布は、等間隔表現[1]、[2]、[3]を一般化し、（ほぼ間違いなく）（一般的な）文字列表現[4]と同等です。

文字列に対する確率分布の利点の1つは、前者が明確であることです。

[5-1]は、既存の分布に（ほとんど）一致する値、たとえば特定の分布に一致することが測定値がわかっている（または考えられている）デバイスから出力される日時値に適しています。

[5-2]は、おそらく任意の「ファジー日時」値をコンパクトに表現するための最良の（ある程度）実用的な方法です。もちろん、使用される特定の確率分布の計算可能性は重要であり、異なる値をクエリ、ソート、または比較するときに解決すべき間違いなく興味深い（そしておそらく不可能な）問題がありますが、これの多くはおそらく既に知られているか、既存のどこかで解決されています数学文献と統計文献ですので、これは間違いなく非常に一般的で曖昧でない表現です。

私はジェームス・アンダーソンのソリューションが本当に好きです-日付を正確に区切ることは、最も柔軟なクエリ構造を取得する方法です。同じことを達成する別の方法は、開始、終了、またはセンターdateとプラスinterval（少なくともPostgreSQL、Oracle、およびSQLAlchemyで使用可能）を使用することです。

あなたの場合、年、月、日のみが必要です。年と月は必須ですが、日はオプションです。私はそのようなものを使用します：

year smallint not null,
month smallint not null,
day smallint

さらに、インデックスを非常に効果的に使用できます。（tiny =マイナス、queires はもう少し「複雑」（長く）になります。

通常の日付の正確な時刻を保存し、ファジー日付の時刻部分を00:00:00のように汎用的にします。それから、すべてのあいまいな日付を月の1日にします。

クエリを実行すると、

1. 時刻が00:00:00（ファジー）に等しい日付範囲を確認します
2. 時間が00:00:00（実際）と等しくない日付範囲を確認します
3. 日付範囲をチェックしますが、時間部分は無視します（組み合わせ）

これよりも優れたソリューションがありますが、個人的にはメタデータ（データに関するデータ）が嫌いです。しばらくすると手に負えなくなるという癖があります。