Under which category would you file this issue?
Airflow Core
Apache Airflow version
airflow 3.2.2 / airflow-ctl 0.1.5 (also present on main)
What happened and how to reproduce it?
airflowctl dagrun list (and any other auto-generated CLI command with a datetime.datetime-typed parameter, e.g. --start-date/--end-date) rejects every possible input string. No date format — plain date, full ISO-8601, anything — will parse.
Reproduction:
airflowctl dagrun list -e <env> --start-date "2026-07-01" --limit 1
# argument --start-date: invalid datetime value: '2026-07-01'
airflowctl dagrun list -e <env> --start-date "2026-07-01T00:00:00" --limit 1
# argument --start-date: invalid datetime value: '2026-07-01T00:00:00'
Root cause:
In airflow-ctl/src/airflowctl/ctl/cli_config.py, _python_type_from_string builds the argparse type= callable for CLI arguments straight from the OpenAPI-derived operation signatures:
mapping: dict[str, type | Callable] = {
"int": int,
"float": float,
"bool": bool,
"str": str,
"bytes": bytes,
"list": list,
"dict": json_dict_type,
"tuple": tuple,
"set": set,
"datetime.datetime": datetime.datetime,
"dict[str, typing.Any]": json_dict_type,
}
For any parameter annotated datetime.datetime, this passes the bare datetime.datetime class to argparse as type=. argparse then calls type(value) on
the raw CLI string, i.e. datetime.datetime("2026-07-01") — invoetime.datetime(year, month, day, ...)), not a parser. Since theconstructor expects positional ints, passing a single string always raises a TypeError, which argparse reports as invalid datetime value: '...'` regardless
of the input.
Notably, the exact same class of bug existed for dict-typed parxed by mapping to json_dict_type (a real parser usingjson.loads) instead of the bare dict constructor. The datetime.datetime entry was missed and still uses the bare type.
What you think should happen instead?
datetime.datetime should map to an actual parsing function, not the bare class, e.g.:
def iso_datetime_type(val: str) -> datetime.datetime:
"""Parse an ISO-8601 datetime string."""
try:
return datetime.datetime.fromisoformat(val)
except ValueError as e:
raise argparse.ArgumentTypeError(f"invalid datetime value: {val!r}") from e
and:
"datetime.datetime": iso_datetime_type,
This mirrors the existing fix pattern already used for dict → `e mapping.
Operating System
macOS (also confirmed against a production Airflow instance, running Linux / Debian distroless)
Deployment
Other
Apache Airflow Provider(s)
No response
Versions of Apache Airflow Providers
Installed via uv tool install apache-airflow-ctl. This bug report is explicitly about the airflowctl tool.
Official Helm Chart version
Not Applicable
Kubernetes Version
Not Applicable
Helm Chart configuration
Not Applicable
Docker Image customizations
Not Applicable
Anything else?
Confirmed present at:
- Tag
airflow-ctl/0.1.5 (commit 30e72a3) — airflow-ctl/src/airflowctl/ctl/cli_config.py:517
main (as of 2026-07-22) — same file, cli_config.py:549, unchanged
Affects every argparse-generated CLI command whose underlying operation signature has a datetime.datetime-typed parameter (e.g. dagrun list --start-date/--end-date), not just this one command.
Are you willing to submit PR?
Code of Conduct
Under which category would you file this issue?
Airflow Core
Apache Airflow version
airflow 3.2.2 / airflow-ctl 0.1.5 (also present on
main)What happened and how to reproduce it?
airflowctl dagrun list(and any other auto-generated CLI command with adatetime.datetime-typed parameter, e.g.--start-date/--end-date) rejects every possible input string. No date format — plain date, full ISO-8601, anything — will parse.Reproduction:
Root cause:
In
airflow-ctl/src/airflowctl/ctl/cli_config.py,_python_type_from_stringbuilds the argparsetype=callable for CLI arguments straight from the OpenAPI-derived operation signatures:For any parameter annotated
datetime.datetime, this passes the baredatetime.datetimeclass to argparse astype=. argparse then callstype(value)onthe raw CLI string, i.e.
datetime.datetime("2026-07-01")— invoetime.datetime(year, month, day, ...)), not a parser. Since theconstructor expects positional ints, passing a single string always raises aTypeError, which argparse reports asinvalid datetime value: '...'` regardlessof the input.
Notably, the exact same class of bug existed for
dict-typed parxed by mapping tojson_dict_type(a real parser usingjson.loads) instead of the baredictconstructor. Thedatetime.datetimeentry was missed and still uses the bare type.What you think should happen instead?
datetime.datetimeshould map to an actual parsing function, not the bare class, e.g.:and:
This mirrors the existing fix pattern already used for
dict→ `e mapping.Operating System
macOS (also confirmed against a production Airflow instance, running Linux / Debian distroless)
Deployment
Other
Apache Airflow Provider(s)
No response
Versions of Apache Airflow Providers
Installed via
uv tool install apache-airflow-ctl. This bug report is explicitly about the airflowctl tool.Official Helm Chart version
Not Applicable
Kubernetes Version
Not Applicable
Helm Chart configuration
Not Applicable
Docker Image customizations
Not Applicable
Anything else?
Confirmed present at:
airflow-ctl/0.1.5(commit30e72a3) —airflow-ctl/src/airflowctl/ctl/cli_config.py:517main(as of 2026-07-22) — same file,cli_config.py:549, unchangedAffects every argparse-generated CLI command whose underlying operation signature has a
datetime.datetime-typed parameter (e.g.dagrun list --start-date/--end-date), not just this one command.Are you willing to submit PR?
Code of Conduct