У меня совет, он не абсолютный конечно, но в большинстве случаев экономит время нервы и работает ЗНАЧИТЕЛЬНО эффективнее (меньше тратит процессорное время как бакэнд так и сервера базы данных)
храните время в виде числа timestamp - количество секунд, по ситуации, в большинстве случаев хватает unixtime, очень редко может потребоваться хранить 64-битный long количества миллисекунд (timestamp*1000).
Исторические даты (старее 1 января 1970) да, лучше хранить в формате, понимаемом базой данных (если нужно делать сравнение < >, сортировку и другие операции).
Большинство преобразований и работа может быть выполнена на бакэнде, зачастую на сервере вычисления и сравнения можно делать в секундах, а граничные значения подготавливать на бакэнде.
Неужели вам самим не корежит постоянное преобразование строкового представления даты туда сюда? А потом где-нибудь ошибетесь с часовым поясом и вылезут ошибки такого вида как у автора вопроса.
p.s. у sqlite нет типа date (там как я понимаю строка) но есть функции работы со временем
https://www.sqlite.org/datatype3.html#date_and_tim...
https://www.sqlite.org/lang_datefunc.html
на самом деле там веселее sqlite сохраняет данные в том типе, который вы попытаетесь записать, когда вы пишете тип date то это ничего не значит, и если дальше записать строку с датой, запишется строка, если число - будет число, дальнейшая работа зависит от того какую функцию скормишь этим данным
если проведете бенчмарки, все это великолепие работает отвратительно, и имеет смысл когда в консоли sqlite делаешь анализ, и все эти now, before, 'one day' очень все облегчают, но когда пишешь код, проще работать с понятными секундами, для которых на других языках разработано огромное количество хелперов