Django数据库查询中的时间范围陷阱：end_date为何需加一天？
在使用Django ORM进行数据库查询，特别是涉及时间范围筛选时，常常会遇到一些令人费解的问题。本文将详细解释一个常见场景：使用__range参数进行时间范围查询时，为什么结束日期end_date通常需要加一天才能包含所有预期数据。
问题：开发者使用以下代码进行查询：
result = amazonhistoryprice.objects.filter(identification=identification,created_at__range=[start_date, end_date]).order_by('created_at').all()
数据库表结构：
create table "amazon_app_amazonhistoryprice" ("id" integer not null primary key autoincrement, "month" integer not null, "day" integer not null, "identification" text not null, "price" integer not null, "year" integer not null, "created_at" datetime null);
结果发现，end_date当天数据缺失。
原因：Django的__range查询默认是包含起始日期和结束日期的（闭区间）。如果created_at字段精确到秒，那么end_date也必须精确到秒，并且end_date本身的值不会被包含在查询结果中。为了包含end_date当天数据，需要将其后移一天。
解决方案一：增加一天
from datetime import datetime, timedelta
end_date = end_date + timedelta(days=1) # 将end_date加一天
result = amazonhistoryprice.objects.filter(identification=identification,created_at__range=[start_date, end_date]).order_by('created_at').all()
解决方案二：使用__gte和__lt
更清晰、更可靠的方法是使用__gte（大于等于）和__lt（小于）：
result = AmazonHistoryPrice.objects.filter(identification=identification, created_at__gte=start_date, created_at__lt=end_date).order_by('created_at').all()
此方法明确定义了左闭右开的区间，避免了__range潜在的边界问题。
总结：这并非__range的缺陷，而是对数据库日期时间类型和查询逻辑理解不足导致的。理解数据库日期时间的存储方式和__range的区间定义，是正确使用Django ORM进行时间范围查询的关键。 推荐使用__gte和__lt来避免此类问题。
