如何配置Azure Function实现多时区适配的定时邮件发送

核心原则：不要手动硬编码时区时差，优先利用Azure Function原生能力或者标准时区API自动适配夏令时，避免时间计算错误。

方案1：双独立定时器配置（最推荐，维护成本最低） #

Azure Function 定时器触发器原生支持指定触发时区，不需要额外写时间转换代码，两个定时器各管一个时区的发送逻辑，完全隔离不会互相影响：

• UTC用户发送定时器：直接配置CRON表达式为0 0 10 * * *，不额外指定时区（默认使用UTC时间），每日UTC时间10点整触发，触发后执行UTC时区用户的邮件推送即可。
• EST（佛罗里达）用户发送定时器：CRON表达式同样配置为0 0 10 * * *，显式指定触发器的时区参数，平台会自动按照对应时区的本地时间计算触发点，自动适配佛罗里达的夏令时切换（每年3-11月为夏令时，和UTC时差4小时，其余时间时差5小时）。
  • 如果是Linux/容器环境部署Function，scheduleTimeZone参数填IANA标准时区IDAmerica/New_York
  • 如果是Windows环境部署Function，scheduleTimeZone参数填Windows时区IDEastern Standard Time

EST定时器的function.json配置示例：

{
  "bindings": [
    {
      "name": "timer",
      "type": "timerTrigger",
      "direction": "in",
      "schedule": "0 0 10 * * *",
      "scheduleTimeZone": "America/New_York"
    }
  ]
}

方案2：单高频轮询定时器+代码内时区判断（适合多时区扩展场景） #

如果后续需要新增更多不同时区的10点发送需求，不想每加一个时区就新增一个Function，可以用轮询方案：

• 配置单个固定间隔定时器，CRON表达式设为0 */5 * * * *，即每5分钟触发一次，时间误差控制在5分钟内，不会产生过高的运行开销。
• 每次触发时，先获取当前UTC时间，通过标准时区API分别转换为各个目标时区的本地时间，判断对应时区的本地时间是否落在当日10点的5分钟窗口内，匹配到对应时区就执行该时区用户的邮件发送。

核心时间判断代码示例（C#）：

// 获取当前UTC时间
DateTime currentUtcTime = DateTime.UtcNow;

// 校验UTC时区是否到发送窗口
DateTime utcLocalTime = currentUtcTime;
if (utcLocalTime.Hour == 10 && utcLocalTime.Minute < 5)
{
    // 执行UTC用户邮件发送逻辑
}

// 校验EST（佛罗里达）时区是否到发送窗口
// Linux/容器环境用这句
TimeZoneInfo estTimeZone = TimeZoneInfo.FindSystemTimeZoneById("America/New_York");
// Windows环境替换为下面这句
// TimeZoneInfo estTimeZone = TimeZoneInfo.FindSystemTimeZoneById("Eastern Standard Time");
DateTime estLocalTime = TimeZoneInfo.ConvertTimeFromUtc(currentUtcTime, estTimeZone);
if (estLocalTime.Hour == 10 && estLocalTime.Minute < 5)
{
    // 执行EST用户邮件发送逻辑
}

避坑提醒：绝对不要硬编码UTC和EST的固定时差，夏令时切换时固定时差会导致发送时间偏移1小时，必须使用系统/语言标准库提供的时区转换能力自动处理夏令时规则。

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