Django 如何基于模板指定格式对DateTime字段做文本过滤查询

底层存储规则说明 #

• DateTimeField的存储格式不完全依赖具体数据库：Django ORM会把时间值统一转成带时区的标准化时间对象，再适配对应数据库的原生时间类型存储，你测试看到的2020-05-12 18:58:23.210862+00这类类字符串内容，是ORM为了执行查询临时生成的UTC格式匹配文本，不是数据库实际存储的纯文本内容。
• 之前用icontains的测试结果刚好能印证这一点：搜2020、2020-08、33这类UTC格式里本来就存在的片段能正常匹配，是因为这些内容直接出现在底层的UTC匹配文本里；而Aug、6:33、p.m这类只在模板展示阶段出现的内容，因为从来不会进入数据库存储层，所以永远无法通过原生DateTime字段的icontains匹配到。

跨字段统一检索的可落地方案 #

核心需求是用同一个检索词，同时匹配所有CharField的文本内容、以及DateTime字段模板展示形态的内容，可以通过两种常规方案实现：

方案1：查询层动态拼接时间匹配条件，不改动表结构 #

不需要修改模型字段，在查询时把DateTime字段拆成可匹配的维度（年、月、日、时、分），对应你的展示格式把每个维度的文本值映射成匹配条件，和CharField的检索条件用Q对象拼接即可。
参考实现：

from django.db.models import Q

search_term = "Aug"
# 月份缩写映射要和你模板展示的格式完全对齐（比如Aug.是否带句点、缩写是否一致）
month_abbr = {
    1: "Jan.", 2: "Feb.", 3: "Mar.", 4: "Apr.", 5: "May.",
    6: "Jun.", 7: "Jul.", 8: "Aug.", 9: "Sep.", 10: "Oct.",
    11: "Nov.", 12: "Dec."
}

# 构造DateTime字段的匹配条件
date_match = Q(created__month__in=[
    month_num for month_num, abbr in month_abbr.items() 
    if search_term.lower() in abbr.lower()
]) | Q(created__year__icontains=search_term) | Q(created__day__icontains=search_term) | Q(created__hour__icontains=search_term) | Q(created__minute__icontains=search_term)

# 拼接所有CharField的匹配条件，做统一检索
full_query = date_match | Q(title__icontains=search_term) | Q(content__icontains=search_term)
Entry.objects.filter(full_query)

• 优点：无冗余存储，不需要调整表结构，适合低检索频率的场景；
• 缺点：如果模板的格式化逻辑比较复杂（比如严格对应12小时制的a.m./p.m.标识、非标准月份缩写），需要手动把每一段格式化逻辑拆成数据库查询条件，适配成本较高。

方案2：冗余存储格式化后的时间文本，统一检索逻辑 #

如果检索频率高、对查询性能要求高，最省事的做法是在模型里新增一个CharField，专门存储和模板展示完全一致的时间字符串：
模型定义参考：

class Entry(models.Model):
    created = models.DateTimeField()
    # 关闭后台编辑权限，避免手动修改造成格式不一致
    created_display = models.CharField(max_length=100, editable=False)

    def save(self, *args, **kwargs):
        # 每次保存记录时，用和模板完全相同的格式化规则生成展示文本
        self.created_display = self.created.strftime("%b. %d, %Y, %-I:%M %p")
        super().save(*args, **kwargs)

检索时直接把这个字段和其他CharField放在一起做模糊匹配，逻辑和普通文本检索完全一致：

search_term = "Aug"
Entry.objects.filter(
    Q(created_display__icontains=search_term) |
    Q(title__icontains=search_term) |
    Q(content__icontains=search_term)
)

• 优点：检索逻辑完全统一，不管检索词是「Aug」「6:33」「p.m」还是「2020」，匹配行为和普通文本字段完全一致，查询性能好，能实现接近通用搜索引擎的统一检索体验；
• 缺点：需要额外的冗余字段，注意批量修改created字段时要同步更新created_display的值，避免数据不一致。

展示格式检索的结论 #

完全可以实现基于模板展示格式的DateTime字段检索，但不能直接对原生DateTime字段做icontains匹配——必须通过上述两种方式，把格式化后的时间文本纳入可检索范围，才能实现输入「Aug」就匹配到对应时间条目、同时匹配其他CharField包含对应关键词内容的效果。

内容的提问来源于stack exchange，提问作者Derrick