Apache Airflow调度器为何在UTC 00:00重置毫秒？数据丢失求助

问题根源 #

你的Airflow调度器在UTC 00:00时会把任务执行时间的毫秒数强制置为0，而你是按分钟拉取上一分钟的数据——比如零点时，调度器给的执行时间是00:00:00.000，按这个时间计算上一分钟范围的话，会漏掉23:59:00.001到23:59:59.999这部分数据，直接从23:59:00.000取到00:00:00.000，等于少了最后几秒的内容。

具体解决方法 #

1. 手动计算精确时间区间（适配所有Airflow版本） #

别直接用调度器给出的execution_date，自己生成完整的上一分钟时间范围：

from datetime import datetime, timedelta

def get_full_last_minute(execution_date):
    # 上一分钟起始：整分钟，毫秒清零
    last_min_start = (execution_date - timedelta(minutes=1)).replace(second=0, microsecond=0)
    # 上一分钟结束：保留原始execution_date的精确值，不截断毫秒
    last_min_end = execution_date
    return last_min_start, last_min_end

在任务中调用这个函数拿到时间范围后再拉取数据，就能覆盖完整的一分钟内容。

2. 使用Airflow 2.x原生数据区间（推荐） #

如果是Airflow 2.0及以上版本，直接用data_interval_start和data_interval_end变量，它们是官方设计的精确分钟级区间：

def execute(self, context):
    start_time = context["data_interval_start"]
    end_time = context["data_interval_end"]
    # 拉取[start_time, end_time)之间的数据，就是完整的上一分钟内容

这种方式无需手动计算，完全贴合Airflow的调度逻辑，避免出错。

3. 检查调度器配置 #

确认Airflow核心配置里的default_timezone为UTC（默认就是该设置，一般无需修改）；如果使用CeleryExecutor，排查是否存在强制截断时间毫秒的配置，将这类配置关闭。

验证方式 #

在零点前后手动触发一次任务，检查拉取的时间范围是否包含23:59:00到00:00:00的所有数据，确认没有遗漏。

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