Where should DataInterval invariants be enforced in Airflow?

[jaymasiwal]

Hi maintainers,

While working around timetables and scheduling, I ran into a design question
related to DataInterval.

Conceptually, DataInterval assumes two invariants:

• start and end are timezone-aware
• end is not earlier than start

Before attempting any changes, I wanted to clarify the intended design boundaries:

• Where are DataInterval invariants expected to be enforced today?
  • At object construction?
  • During timetable validation?
  • At DAG parsing or runtime boundaries?
• Is the current permissive behavior intentional (e.g. to support legacy runs,
  serialized DAGs, or external integrations)?

I’m not proposing a behavior change here — just trying to understand where
validation is expected to live so future docs or tests align with that intent.

Thanks for any guidance.

[potiuk]

There were lots of discussions on that and I think the current conclusion and intention is expressed here (but you might want to follow earlier discussions):

https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=337676722#Option2clarificationdocWIP-Resolutionofquestions

Earlier discussions:

• https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-83+Rename+execution_date+-%3E+logical_date+and+make+logical_date+optional
• https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-83+amendment+to+support+classic+Airflow+authoring+style

If you find any missing or unclear implementation or things to improve related to those conclusions, PRs to fix those are best way to discuss it. Ideally - if you see any improvement to current implementation - opening a PR with a proposal to improve it, and justification (ideally referring to those earlier discussions) is a good idea.

Also if you feel that better capturing of the current state is needed, the best way to fix it is that someone like you - who is trying to figure it out, make a PR and propose it in the way they understand it - then when we see PR we will be able to point out any misunderstanding and things to correct before merge. This is by far most efficient and best way to create such a documentation - because people like you are best to formulate the explanations in the way that other people like you who have no earlier assumptions will find easiest to understand and learn from

[jaymasiwal]

Thanks, this is very helpful.
I’ll read through the linked AIP-83 materials and put together a small documentation PR that captures the current intended behavior and boundaries, without changing runtime semantics.
I’ll reference those discussions directly so it’s clear how the explanation aligns with prior decisions.