这个问题确实和英国夏令时（DST）的跳转直接相关，我来帮你拆解清楚：

首先明确夏令时的时间变化 #

2020年3月29日（周日），英国正式进入夏令时，时钟会在凌晨直接从00:00跳到01:00——这意味着伦敦时间的2020-03-29 00:00这个时间点根本不存在，属于“丢失的一小时”。

你的DAG调度逻辑与预期冲突的原因 #

你的DAG设置了tz=Europe/London，调度规则0 0 * * 1-5表示每个工作日的伦敦时间午夜00:00触发。对于2020-03-27（周五）的运行实例，正常逻辑下：

• 首先跳过2020-03-28（周六，非工作日）；
• 2020-03-29是周日（非工作日），且00:00时间点不存在，也会被跳过；
• 下一个有效触发时间应该是2020-03-30（周一）的00:00伦敦时间，对应的next_ds应该是2020-03-30。

为什么实际next_ds是2020-03-29？ #

这大概率是旧版本Airflow（1.x系列）的夏令时处理缺陷导致的：

• 在Airflow 1.x的部分版本中，时区感知DAG的调度计算没有正确识别“不存在的时间点”，会错误地将调整后的时间（比如2020-03-29 01:00伦敦时间，属于周日）的日期作为next_ds，即使这个时间点并不符合你设定的“工作日”调度规则。
• 另外，next_ds本质是next_execution_date的日期字符串，如果next_execution_date被错误计算为那个周日的01:00，对应的日期自然就是2020-03-29。

解决建议 #

• 升级到Airflow 2.x：新版本彻底重构了时区和调度逻辑，对夏令时跳转的处理更加严谨，这类计算错误已经被修复。
• 验证next_execution_date的完整值：可以在DAG中添加一个简单任务（比如PythonOperator），打印next_execution_date的完整时区信息，确认它是否正确指向2020-03-30 00:00 Europe/London，这样能更直观地定位问题。

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