.NET Core 2.2下Hangfire作业未按设定时间触发无报错求助

• 核心问题是时区识别与调度计算偏移，你在数据库查到的StartedAt字段是以UTC格式存储的时间，结合实际触发时间比预设7点晚6个多小时的特征，大概率是Hangfire版本和运行环境的时区兼容问题：
  • 你使用的Hangfire 1.6.22是早期面向.NET Framework设计的版本，对TimeZoneInfo参数的解析逻辑在.NET Core 2.2运行时（尤其是Linux容器部署场景）存在天然兼容缺陷：该版本解析时区时依赖Windows系统注册表的时区定义，在.NET Core 2.2环境下传入TimeZoneInfo.Local时，经常会出现运行时自动识别的时区和服务器实际时区不一致的问题。
  • 可以做1分钟快速验证：在代码里加一行临时日志，打印TimeZoneInfo.Local.Id、TimeZoneInfo.Local.GetUtcOffset(DateTime.Now)的实际输出，就能发现运行时识别的本地时区大概率和你预期的东八区（UTC+8）存在明显偏差。
• 之前把Cron从7点改成7点10分仍然不生效的原因：
  • RecurringJob的调度状态是持久化存在数据库里的，第一次用错误时区注册作业时，生成的下次触发时间已经存在偏差，后续仅修改Cron值时，如果没有触发作业配置的全量更新，Hangfire不会重新基于正确时区计算触发时间，自然会出现长时间不触发的情况。
• 具体可落地的解决步骤：
  • 改掉代码里的时区传参，不要依赖自动识别的TimeZoneInfo.Local，改为显式指定固定时区：
    • Windows部署环境用TimeZoneInfo.FindSystemTimeZoneById("China Standard Time")
    • Linux容器部署环境用TimeZoneInfo.FindSystemTimeZoneById("Asia/Shanghai")
    • 从根源上避免运行时自动识别时区带来的不确定性
  • 清空旧的调度缓存：打开Hangfire Dashboard找到对应的RecurringJob，删除原有旧配置，再重启应用执行一次作业注册逻辑，让Hangfire用修正后的时区参数重新计算下次触发时间
  • 提前校验触发时间：打开该RecurringJob的详情页，查看Next Execution字段的具体时间，把这个时间转换为本地时区时间，确认和预期的7点/7点10分一致后，再等待自动触发即可，避免反复等不到触发浪费时间。
• 补充提醒：
  • 你当前用的Hangfire 1.6.22是2019年发布的老版本，本身就存在不少调度计算的已知bug，后续如果有版本升级的空间，建议直接升级到1.7.x稳定版，该版本已经完整适配.NET Core环境的时区解析逻辑，不会出现这类偏移问题。

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