История изменений
Исправление hobbit, (текущая версия) :
Из документа
Вооот. Значит, надо осмыслить, что за долб оригиналы такой документ делали, и что это означает.
Я бы первым делом посмотрел, в этих документах все даты в таком виде или только некоторые? Если все, то в БД надо просто вместо даты ввести год и не париться. Если только некоторые, то второй вопрос – что эти нули означают.
Наиболее вероятная гипотеза, которую выдвинули выше — когда известен только год, но даже год имеет ценность. В таком случае тебе преобразование совершенно адекватно предлагает 1 января. Просто в таблице рядом с датой надо ввести дополнительное поле only_year, а перед укладкой в базу проверять, нули там или нет. Если нули, помечаем, что известен только год, если нет, пишем всё. И если документ такого же формата надо будет ещё и формировать, делаем обратную операцию, если only_year выставлен в true, превращаем месяц и день на выходе в нули, чтобы отличить их от реального 1 января.
Ну или как предложили выше, вместо даты просто забульбенить (c) 
Eddy_Em строковое поле. Но это перекладывание контроля целостности данных с БД на прикладной уровень и в общем случае это фу. Разобраться с проблемой всё же предпочтительнее.
Короче, предметную область надо анализировать. А так, как сформулировано в ОП – это Проблема XY в сочетании с 4.2 :)
Исправление hobbit, :
Из документа
Вооот. Значит, надо осмыслить, что за долб оригиналы такой документ делали, и что это означает.
Я бы первым делом посмотрел, в этих документах все даты в таком виде или только некоторые? Если все, то в БД надо просто вместо даты ввести год и не париться. Если только некоторые, то второй вопрос – что эти нули означают.
Наиболее вероятная гипотеза, которую выдвинули выше — когда известен только год, но даже год имеет ценность. В таком случае тебе преобразование совершенно адекватно предлагает 1 января. Просто в таблице рядом с датой надо ввести дополнительное поле only_year, а перед укладкой в базу проверять, нули там или нет. Если нули, помечаем, что известен только год, если нет, пишем всё. И если документ такого же формата надо будет ещё и формировать, делаем обратную операцию, если only_year выставлен в true, превращаем месяц и день на выходе в нули, чтобы отличить их от реального 1 января.
Ну или как предложили выше, вместо даты просто забульбенить (c) Eddy_Em строковое поле. Но это перекладывание контроля целостности данных с БД на прикладной уровень и в общем случае это фу.
Короче, предметную область надо анализировать. А так, как сформулировано в ОП – это Проблема XY в сочетании с 4.2 :)
Исходная версия hobbit, :
Из документа
Вооот. Значит, надо осмыслить, что за долб оригиналы такой документ делали, и что это означает.
Я бы первым делом посмотрел, в этих документах все даты в таком виде или только некоторые? Если все, то в БД надо просто вместо даты ввести год и не париться. Если только некоторые, то второй вопрос – что эти нули означают.
Наиболее вероятная гипотеза, которую выдвинули выше — когда известен только год, но даже год имеет ценность. В таком случае тебе преобразование совершенно адекватно предлагает 1 января. Просто в таблице рядом с датой надо ввести дополнительное поле only_year, а перед укладкой в базу проверять, нули там или нет. Если нули, помечаем, что известен только год, если нет, пишем всё. И если документ такого же формата надо будет ещё и формировать, делаем обратную операцию, если only_year выставлен в true, превращаем месяц и день на выходе в нули, чтобы отличить их от реального 1 января.
Короче, предметную область надо анализировать. А так, как сформулировано в ОП – это Проблема XY в сочетании с 4.2 :)