DateTimeOffset在Azure App Service部署后解析报错如何解决

• 直接触发报错的原因是2018年不是闰年，不存在2月29日这个日期，拼接出的时间字符串本身不合法，无法被解析。
• 根本原因是你的实现依赖字符串拼接和默认规则的时间解析，不同环境的区域文化配置存在差异：
  1. 本地环境的系统区域文化和Azure App Service默认区域文化不同，StartDate/EndDate隐式转为字符串的格式不一致，拼接后得到了不符合预期的日期字符串。
  2. DateTimeOffset.Parse默认使用当前线程的区域文化规则解析字符串，本地环境能正常识别的格式，在Azure环境下解析出错，最终生成了不存在的非法日期。
  3. 硬编码固定时区偏移-04:00的逻辑本身不严谨，没有考虑夏令时变更、输入日期时区不匹配的问题，也加大了日期出错的概率。

完全避免字符串拼接构造时间的逻辑，直接操作时间对象，同时固定解析规则与时区逻辑，消除不同环境的差异影响：

1. 若输入的StartDate、EndDate本身是DateTime类型，直接通过时间对象属性构造当日起止时间，不需要转字符串：

// 提前定义业务需要的UTC-4对应时区，示例为美国东部标准时间，可根据实际需求替换时区Id
var targetTimeZone = TimeZoneInfo.FindSystemTimeZoneById("Eastern Standard Time");

// 构造当日起始时间（对应时区的零点）
var startDate = TimeZoneInfo.ConvertTimeToUtc(
    new DateTime(StartDate.Year, StartDate.Month, StartDate.Day, 0, 0, 0, DateTimeKind.Unspecified), 
    targetTimeZone);

// 构造次日零点作为结束边界，查询时用 时间字段 < endDate 即可覆盖当日全部时间，无需处理毫秒级边界
var endDate = TimeZoneInfo.ConvertTimeToUtc(
    new DateTime(EndDate.Year, EndDate.Month, EndDate.Day, 0, 0, 0, DateTimeKind.Unspecified), 
    targetTimeZone).AddDays(1);

2. 若输入的StartDate、EndDate是字符串格式，使用ParseExact固定解析格式与文化，避免环境差异影响：

using System.Globalization;

var targetTimeZone = TimeZoneInfo.FindSystemTimeZoneById("Eastern Standard Time");

// 固定解析格式为yyyy-MM-dd，使用不变文化
var startDateDate = DateTime.ParseExact(StartDate, "yyyy-MM-dd", CultureInfo.InvariantCulture);
var startDate = TimeZoneInfo.ConvertTimeToUtc(
    new DateTime(startDateDate.Year, startDateDate.Month, startDateDate.Day, 0, 0, 0, DateTimeKind.Unspecified), 
    targetTimeZone);

var endDateDate = DateTime.ParseExact(EndDate, "yyyy-MM-dd", CultureInfo.InvariantCulture);
var endDate = TimeZoneInfo.ConvertTimeToUtc(
    new DateTime(endDateDate.Year, endDateDate.Month, endDateDate.Day, 0, 0, 0, DateTimeKind.Unspecified), 
    targetTimeZone).AddDays(1);

3. 额外优化查询逻辑：存储过程中时间范围判断使用时间字段 >= startDate AND 时间字段 < endDate，比判断<= 当日23:59:59的逻辑更严谨，不会漏掉毫秒级的时间数据。

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