OData V2服务中日期筛选未正确生效问题求助

问题场景 #

• 前端使用DateRangeSelection组件选择日期01.07.2024（格式：dd.mm.yyyy），调试前端filter对象确认该值正确。
• 后端OData服务实现中，IV_FILTER_STRING接收到的筛选条件为：(( PurchaseOrderDate ge '20240106' ) and ( PurchaseOrderDate le '20240106' ))，日期与前端选择值完全不符。

可能原因及排查/解决方法 #

1. 日期格式解析歧义 #

前端传递的日期格式（dd.mm.yyyy）与后端OData服务默认解析格式不匹配，导致月日颠倒，再叠加时区偏移出现日期偏差。比如后端默认按mm.dd.yyyy解析01.07.2024，会把01识别为月份、07识别为日期，再加上时区转换导致日期减1，最终得到20240106。

排查：

• 查看前端发送的OData请求URL，确认实际传递的日期参数字符串格式。
• 检查后端OData服务的日期解析配置（比如ABAP系统的默认日期格式设置）。

解决：

• 前端统一将日期转换为OData标准格式yyyy-MM-dd（如2024-07-01）后再发送请求，避免格式歧义。
• 后端配置明确的日期解析规则，与前端传递格式保持一致。

2. 时区偏移导致日期转换错误 #

前后端时区不一致，前端选择的本地日期转换为后端时区时出现日期偏移。比如前端处于UTC+8时区，选择的01.07.2024 00:00转换为UTC时区是30.06.2024 16:00，若后端只提取日期部分，会得到前一天的日期，再叠加格式解析错误就会出现20240106的异常值。

排查：

• 对比前后端的时区设置，确认是否存在时区差。
• 查看前端日期对象的UTC时间值，验证转换后的日期是否正确。

解决：

• 统一前后端时区（比如均使用UTC），前端转换日期时显式指定时区，例如使用Date.UTC()构建UTC日期后再生成字符串。
• 后端处理日期时，明确基于前端传递的时区信息进行解析，避免自动转换。

3. DateRangeSelection组件配置问题 #

组件的format属性未正确设置，导致输出的日期格式不符合预期，或组件内部自动进行了格式转换。

排查：

• 检查DateRangeSelection的format属性是否设置为dd.MM.yyyy，确保组件输出的日期格式与预期一致。

解决：

• 显式指定组件的日期格式，禁止自动转换，确保前端传递的日期字符串与选择值一致。

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