关于Acumatica LastModifiedDateTime过滤逻辑的技术问询

实现背景 #

• 版本：22.200.001
• 接口类型：Rest API
• 请求方式：GET
• 过滤参数规则：使用$filter参数，取值格式为 LastModifiedDateTime gt "yyyy-MM-ddThh:mm:ss.000"
• 适用范围：所有接口端点

问题现象 #

当执行LastModifiedDateTime gt "yyyy-MM-ddThh:mm:ss.000"过滤请求时，系统返回的并非实际大于指定时间戳的记录，而是返回指定日期当天00:00:00.000至23:59:59.999的全部记录。

核心疑问 #

1. 该行为属于设计预期还是程序Bug？
2. 若为设计预期，为何系统要将LastModifiedDateTime字段存储并精确到毫秒级？

技术影响 #

此问题会触发不必要的SQL回滚更新操作：原本通过$filter应该过滤掉的未更新记录，会被错误纳入结果集，导致后续对这些记录执行无意义的更新回滚。虽然可以通过“先查询记录详情再判断是否需要更新”的方式规避，但完全违背了$filter前置过滤的设计初衷，额外增加了系统资源开销与开发复杂度。

见解分析 #

从常规API设计与实现逻辑来看，这种行为更倾向于底层处理Bug：

• 如果是设计预期，存储毫秒级时间戳完全没有价值，只需存储日期维度即可，这种设计既浪费存储资源，也不符合开发者对时间过滤的常规认知。
• 最可能的原因是底层在解析$filter参数时，错误地将时间戳截断到了日期维度，丢弃了时分秒的精度判断，导致gt操作被错误解析为“大于等于指定日期的0点”。
• 另一种可能性是数据库查询语句生成错误：比如将LastModifiedDateTime > '指定时间'错误转换为CAST(LastModifiedDateTime AS DATE) = CAST('指定时间' AS DATE)，从而返回了当天所有记录。

如果确实是设计行为，那么该产品的设计逻辑存在明显矛盾：一方面提供毫秒级的时间存储能力，另一方面过滤时却完全忽略精度，这种设计既不符合开发者的使用预期，也让时间字段的高精度特性失去意义。

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