SQL查询日期边界差一天问题排查（Dapper+DapperQueryBuilder）

核心原因：时间精度丢失与边界判断偏差 #

你遇到的问题本质是日期的时间部分被截断，导致边界条件判断不准确，具体拆解如下：

1. 字符串转换丢失时间信息
   你将DateTime对象通过ToString("MM/dd/yyyy")转换为字符串时，会自动截断时分秒部分，最终得到的endDate对应数据库中的时间戳为2022-09-30 00:00:00.000。但数据库中DInStage字段如果是datetime/datetime2类型（带时分秒），比如某条记录的DInStage实际是2022-09-30 08:15:30，那么用<= '09/30/2022'筛选时，这条记录的时间晚于边界时间，会被排除。

2. Between的边界特性影响
   即便使用Between，SQL中Between虽包含上下限，但同样受限于你传入的endDate是00:00:00的时间点，所有DInStage在2022-09-30当天非凌晨的记录都会被过滤。

3. 日期格式解析的潜在风险
   数据库存储的是欧洲格式日期（30.09.2022），而你传入的是MM/dd/yyyy格式字符串，这次因30超过12未出现解析错误，但硬编码格式的做法易引发跨环境歧义——若某天的日≤12，数据库可能错误地将日当成月，导致更严重的查询错误。

加1天生效的逻辑 #

你将endDate加1天后，得到的字符串对应时间戳2022-10-01 00:00:00.000，此时<= '10/01/2022'会包含所有2022-09-30当天的记录（哪怕时间是23:59:59），因此能返回全部7条数据。

正确解决方案建议 #

• 直接传递DateTime参数（推荐）：利用Dapper的参数化查询能力，不要将DateTime转成字符串。示例：

  DateTime startDate = DateTime.Now.AddDays(-14).Date; // 取当天凌晨
  DateTime endDate = DateTime.Now.Date.AddDays(1); // 取次日凌晨，覆盖当天所有时间
  

  查询语句使用参数：

  WHERE DInStage >= @startDate AND DInStage < @endDate
  

  这种方式既保留时间精度，又避免格式解析问题。
• 若必须用字符串，明确时间边界：将endDate设置为DateTime.Now.ToString("MM/dd/yyyy 23:59:59.999")，但可靠性远不如直接传DateTime参数。

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