Ever wondered why your daily reports sometimes show the wrong date? The secret lies in understanding execution vs logical dates!
Execution date vs logical date in Apache Airflow - When to Use Which
Imagine you run a daily report manually every morning at 9 AM for the previous day's sales data.
You write down the date you run the report and the date the data is actually about, but sometimes you get confused which date to use for naming files or logs.
Manually tracking when you run a task versus what data it covers is confusing and error-prone.
You might overwrite files, mix up reports, or analyze the wrong data because you used the run time instead of the data date.
Airflow uses the execution date as the logical date (the data's date the task processes), separate from when the task actually runs.
This clear distinction helps you organize, track, and automate workflows reliably without mixing up timing and data coverage.
Run report at 9 AM and name file report_2024-06-10.csv (but unsure if date is run date or data date)
Airflow task runs at 9 AM on 2024-06-11 with execution_date=2024-06-10 (logical date) for previous day's data
You can automate workflows that process data for specific dates reliably, even if tasks run later or get delayed.
A daily sales ETL job runs every morning but processes yesterday's sales data using the logical date, ensuring reports always reflect the correct day.
Manual date tracking causes confusion between run time and data date.
Execution date (logical date) is the data's date; run time is when the task runs.
Airflow's separation prevents errors and improves automation reliability.
Practice
logical date in Airflow represent?Solution
Step 1: Understand the definition of logical date
The logical date is the timestamp representing the data interval the task is working on, not when it runs.Step 2: Differentiate from execution date
Execution date is when the task actually runs, but logical date points to the data period it processes.Final Answer:
The time period the task is processing data for -> Option AQuick Check:
Logical date = data period [OK]
- Confusing logical date with actual run time
- Thinking logical date is current system time
- Mixing execution date with DAG creation time
Solution
Step 1: Recall Airflow context variables
Airflow provideslogical_datein the context to represent the logical date of the task instance.Step 2: Identify the correct key for logical date
The key'logical_date'is used to access the logical date, while'execution_date'is deprecated in newer versions.Final Answer:
Usingcontext['logical_date']-> Option BQuick Check:
Access logical date with context['logical_date'] [OK]
- Using deprecated 'execution_date' key
- Trying to access logical date with 'run_time'
- Confusing start_date with logical date
Solution
Step 1: Understand daily scheduling in Airflow
A DAG scheduled daily at midnight runs for the data of the previous day, so the logical date is the start of that previous day.Step 2: Calculate logical date for run on 2024-06-10 00:00 UTC
The run at midnight on June 10 processes data for June 9, so logical date is 2024-06-09 00:00 UTC.Final Answer:
2024-06-09 00:00 UTC -> Option CQuick Check:
Run time = June 10, logical date = June 9 [OK]
- Assuming logical date equals execution date
- Using current system time as logical date
- Confusing next day as logical date
execution_date as 2024-06-10 but the data processed is from 2024-06-11. What is the likely issue?Solution
Step 1: Analyze mismatch between execution_date and data date
If data processed is from a later date than execution_date, the task likely uses execution_date (run time) instead of logical_date (data period) for filtering.Step 2: Understand correct usage of logical date
Logical date should be used to select data for the intended period; using execution_date causes off-by-one errors.Final Answer:
The task is using execution_date instead of logical_date for data filtering -> Option DQuick Check:
Use logical_date for data period, not execution_date [OK]
- Ignoring difference between execution and logical dates
- Assuming schedule interval causes date mismatch
- Blaming system clock without checking code
Solution
Step 1: Understand hourly scheduling and data processing
For hourly DAGs, the logical date marks the start of the hour for which data is processed, typically the previous hour.Step 2: Choose the correct date for filtering data
Using logical_date ensures the task filters data for the correct hour interval, not the actual run time.Final Answer:
Uselogical_datewhich represents the data interval start -> Option AQuick Check:
Hourly data uses logical_date for correct filtering [OK]
- Using execution_date causes off-by-one hour errors
- Using current time ignores schedule intervals
- Confusing DAG start_date with data interval
Ready to prove it?
Pass the test and this pattern moves unknown
