基于.Net控制台的WebJob部署到Azure应用服务后DateTime解析报错求助

• Azure应用服务承载WebJob的进程默认运行区域性为en-US，和本地开发机的zh-CN区域性存在日期格式识别差异，是跨环境触发DateTime解析异常的直接原因
• 现有构造函数逻辑存在无意义的类型转换冗余：

  datetime = DateTime.Parse(DateTime.Now.ToString("dd/MM/yyyy hh:mm:ss"));
  

  这段代码先把原生DateTime类型的DateTime.Now转成dd/MM/yyyy格式的字符串，再依靠当前线程默认的区域性规则把字符串解析回DateTime，全程没有指定固定格式与匹配的区域性规则，完全依赖运行环境的默认区域配置。在Azure的en-US环境下，系统默认识别MM/dd/yyyy的格式约定，遇到dd/MM/yyyy格式中数值大于12的“日”值时，会将其判定为无效月份，直接抛出FormatException。

• 在WebJob启动入口临时增加日志，输出当前线程的区域性标识：
  Console.WriteLine(Thread.CurrentThread.CurrentCulture.Name);
  部署后查看运行日志，基本会输出en-US，与本地默认的zh-CN形成明确差异
• 本地临时修改控制台应用的线程区域性为en-US，可100%复现与Azure环境一致的解析异常，验证问题触发逻辑：

  Thread.CurrentThread.CurrentCulture = new CultureInfo("en-US");
  

1. 优先移除无意义的字符串转换链路
   直接删除构造函数中绕路的ToString+Parse逻辑，给DateTime属性直接赋值即可，从根源上规避所有依赖区域性的字符串解析问题：

   public Items()
   {
       datetime = DateTime.Now;
   }
   

2. 若业务存在固定格式的DateTime字符串解析需求，必须显式指定格式与无区域性差异的解析规则
   不依赖系统默认区域性设置，使用ParseExact配合CultureInfo.InvariantCulture完成解析，确保在任何服务器环境下的解析逻辑一致：

   datetime = DateTime.ParseExact(
       dateString: DateTime.Now.ToString("dd/MM/yyyy hh:mm:ss"),
       format: "dd/MM/yyyy hh:mm:ss",
       provider: CultureInfo.InvariantCulture
   );
   

3. 可选：全局统一WebJob的运行区域性
   若业务需要固定使用zh-CN的日期识别规则，可在Main方法最开头全局覆盖线程的默认区域性配置，抵消Azure环境的默认en-US设置：

   Thread.CurrentThread.CurrentCulture = new CultureInfo("zh-CN");
   Thread.CurrentThread.CurrentUICulture = new CultureInfo("zh-CN");
   

• 现有时间判断逻辑存在逻辑bug：初始化阶段Current_time = obj.datetime; Target_time = Current_time.AddMinutes(55);之后立刻判断if (Current_time >= Target_time)，该分支永远不会触发——因为Target_time比Current_time大55分钟，需要核对业务逻辑的预期分支
• Azure应用服务的服务器默认运行在UTC时区，直接调用DateTime.Now会获取比国内标准时间差8小时的结果，建议改用DateTime.UtcNow，或在应用服务配置中全局设置时区为China Standard Time统一时间基准

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