Django中__date与__month字段查询无法返回对象的问题

以下是可能的原因及排查方向：

1. 时区配置不匹配 #

如果你的Django项目开启了USE_TZ = True，数据库中存储的end_date是UTC时间，但查询时使用的是本地时区的日期/月份参数，就会出现匹配失败。比如：

• 数据库中end_date为2024-03-31 23:00:00 UTC
• 本地时区是Asia/Shanghai（UTC+8），对应本地日期是2024-04-01
• 用end_date__date=date(2024,4,1)查询时，Django会将参数转换为UTC时间的日期范围（2024-03-31 16:00:00到2024-04-01 16:00:00），和数据库中的记录不匹配，但年份2024是一致的，所以__year查询有效。

排查方法：

• 检查settings.py中的TIME_ZONE和USE_TZ配置
• 查询时使用时区感知的对象，比如：

  from django.utils import timezone
  from datetime import datetime
  target_date = timezone.make_aware(datetime(2024,4,1))
  MembershipPlanSubscription.objects.filter(end_date__date=target_date.date())
  

  或者直接构造UTC时区的日期范围查询。

2. 查询参数类型错误 #

如果查询时传入的是字符串格式的日期（比如end_date__date='2024-04-01'），而非datetime.date实例，部分数据库可能会将字符串解析为UTC时区的日期，和实际存储的本地时间（当USE_TZ=False时）不匹配。而__year参数传入数字时，不存在这个解析问题。

排查方法：

• 确保查询参数是datetime.date类型：

  from datetime import date
  MembershipPlanSubscription.objects.filter(end_date__date=date(2024,4,1))
  

3. 数据库函数支持差异 #

不同数据库对Django生成的__date/__month查询SQL的处理逻辑可能有差异，旧版本数据库或Django版本可能存在函数调用错误。比如：

• MySQL使用DATE(end_date)提取日期，PostgreSQL使用DATE_TRUNC('day', end_date)
• 如果Django生成的SQL函数不符合数据库语法，会导致日期/月份提取错误，但年份提取逻辑相对统一，所以__year查询正常。

排查方法：

• 打印查询生成的SQL语句，检查是否正确：

  qs = MembershipPlanSubscription.objects.filter(end_date__date=date(2024,4,1))
  print(qs.query)
  

• 对比数据库原生SQL的执行结果，确认函数调用是否正确，必要时升级Django或数据库版本。

4. 实际数据存储不符 #

你认为数据库中存在对应日期的记录，但实际存储的end_date日期部分可能和查询参数不一致。比如记录的end_date是2024-03-31 23:59:59，查询2024-04-01的__date就会失败，但年份仍为2024，所以__year查询有效。

排查方法：

• 直接在数据库中执行原生SQL验证：

  SELECT * FROM membership_plan_subscription WHERE DATE(end_date) = '2024-04-01';
  

  如果没有返回结果，说明数据本身的日期和预期不符。

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