このところAirflowについて公式資料を読んできた中で、重要概念としてしばしば登場した各種の日付概念をおさらいしておきます。

データ区間（data interval）

ワークフロー（DAG）の実行中に処理対象となるデータの区間（期間）。
バッチ処理の対象となるデータを特定するための情報。
開始日時（data_interval_start）と終了日時（data_interval_end）で示される。

例えば一日ごとに起動するワークフローならば、
「今回」2022-07-23 00:00:00に起動した回のデータ区間は 2022-07-22 00:00:00 から 2022-07-23 00:00:00、
次回のデータ区間は 2022-07-23 00:00:00 から 2022-07-24 00:00:00、
次次回のデータ区間は 2022-07-24 00:00:00 から 2022-07-25 00:00:00、
・・・と推移する。

タスクやオペレーターのPythonコードではcontextオブジェクトを使ってこれらの日時情報を取得できる。例： context['data_interval_start']。
Jinja2テンプレートの中でも同名の変数として利用できる。例：{{ data_interval_start }} ・ {{ data_interval_end }} （参考ページ）。
タスクやオペレーター内のビジネスロジックでは、例えばSQLのフィルタに開始日時と終了日時の条件を加えるなどして、処理対象のデータを制御する。
Web UIではワークフロー（DAG）の「Last Run」や「Next Run」の (!) マークにマウスオーバーすると確認できる。

スケジュール間隔（schedule_interval）

DAGのパラメーターの1つ。
ワークフローのスケジュール実行の起動間隔を定義するもの。
crontabの記法を使用して指定できる。

この間隔でdata intervalが刻まれていく。
例えば@dailyなら1日間隔となり、1日あたり1回実行されるワークフローとなり、data interval も直近24時間を表すものになる。また例えば@hourlyなら1時間間隔となり、1日あたり24回実行されるワークフローとなり、data interval も直近1時間を表すものになる。

開始日時（start_date）

DAGのパラメーターの1つ。
一連のデータ区間（data interval）の最初のものの開始日時。
この日時からschedule_intervalで指定された時間が経過した後、ワークフローは初回起動する。

初回起動の時は一連のデータ区間（data interval）の開始日時と一致する。
つまり start_date ＝ data_interval_start。そして start_date + schedule_interval ＝ data_interval_end。
次回起動の時は start_date + schedule_interval ＝ data_interval_startで、start_date + (schedule_interval * 2) ＝ data_interval_end。

論理日時（logical_date）

旧称： execution_date。v2.2以降、現在の名称になった。
スケジュール実行した場合とそうでないとき（手動実行など）で内容が異なる。
スケジュール実行された場合は、data_interval_start と同じになる。
手動実行された場合は、起動指示が行われた日時になる。

タスクやオペレーターのPythonコードではcontextオブジェクトを使ってこれらの日時情報を取得できる。例： context['logical_date']。
Jinja2テンプレートの中でも変数として利用できる。データ精度やフォーマットにより複数用意されている。例：{{ ds }} や {{ ts }} （参考ページ）。
Web UIではワークフロー実行（DAGRun）の一覧で確認できる。

参考情報

Jinja2テンプレート内で参照できる変数名については公式リファレンスのこちらのページを参考にしました。また、Contextオブジェクトが持つエントリーのキーについては公式リポジトリのこちらのコードを参考にしました。