面向美东订阅者的早报定在本地时间 8 点发,三月第二个周日之后全部变成 7 点送达,打开率掉了 9 个百分点,两边都没人改过配置。碰到这种情况,我一般先确认改动有没有真的生效。
原因不复杂,发送时间存的是服务器本地时间,换算时用了固定的 -05:00 偏移,夏令时开始后美东变成 -04:00,转换结果提前一小时。库里也没有存订阅者时区。
「发送时区夏令时」相关的日志我一般连着看前后五分钟,单看一条报错经常判断不出是哪一步失败。报错里带路径的,先去看那个路径在不在、权限对不对。
from zoneinfo import ZoneInfo
from datetime import datetime
datetime.now(ZoneInfo('America/New_York'))
同一份配置存在多处的,先确认改的是被加载的那一份。
具体做法是,订阅时记录 IANA 时区名,比如 America/New_York,别只存偏移量;发送前用该时区现算一次当地时间,交给系统的时区库处理夏令时;夏令时切换那一周单独核对一次实际送达时间。
最后用这个标准收尾,夏令时切换后的第一次发送仍在当地 8 点送达,前后一周的打开率没有明显落差。
