Fix airflowctl date parameters rejecting every input value

[DHBhensdadia]

_python_type_from_string maps OpenAPI parameter annotations to the argparse type= callable used by auto-generated commands. datetime.date was mapped to the class itself, but argparse calls that callable with the raw string from the command line and date.__init__ expects three integers, so every value was rejected:

$ airflowctl dagrun list --partition-date-gte 2026-07-01
argument --partition-date-gte: invalid date value: '2026-07-01'

The message reads as a complaint about the format, but no input can succeed.

_is_primitive_type accepts datetime.date, and DagRunOperations.list declares partition_date_gte and partition_date_lte as datetime.date | None, so this affects the shipped CLI. The hand-written commands in dag_command.py already parse these values with date.fromisoformat; the generated path had no equivalent.

This adds iso_date_type alongside the existing json_dict_type and wires it into the mapping, so a valid value is parsed into a date and an invalid one reports the format that is actually expected.

datetime.datetime has the same root cause but is left untouched here, since #70249 and #70250 are already open against it. The remaining constructor entries (bytes, list, tuple, set) are not reachable today, as no operation is annotated with them.

related: #70232

---

Was generative AI tooling used to co-author this PR?

• Yes (please specify the tool below)

Generated-by: Claude Code (Opus 5) following the guidelines

---

• Read the Pull Request Guidelines for more information. Note: commit author/co-author name and email in commits become permanently public when merged.
• For fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
• When adding dependency, check compliance with the ASF 3rd Party License Policy.
• For significant user-facing changes create newsfragment: {pr_number}.significant.rst, in airflow-core/newsfragments. You can add this file in a follow-up commit after the PR is created so you know the PR number.

[boring-cyborg]

Congratulations on your first Pull Request and welcome to the Apache Airflow community! If you have any issues or are unsure about any anything please check our Contributors' Guide
Here are some useful points:

• Pay attention to the quality of your code (ruff, mypy and type annotations). Our prek-hooks will help you with that.
• In case of a new feature add useful documentation (in docstrings or in docs/ directory). Adding a new operator? Check this short guide Consider adding an example Dag that shows how users should use it.
• Consider using Breeze environment for testing locally, it's a heavy docker but it ships with a working Airflow and a lot of integrations.
• Be patient and persistent. It might take some time to get a review or get the final approval from Committers.
• Please follow ASF Code of Conduct for all communication including (but not limited to) comments on Pull Requests, Mailing list and Slack.
• Be sure to read the Airflow Coding style.
• Always keep your Pull Requests rebased, otherwise your build might fail due to changes not related to your commits.
  Apache Airflow is a community-driven project and together we are making it better 🚀.
  In case of doubts contact the developers at:
  Mailing List: dev@airflow.apache.org
  Slack: https://s.apache.org/airflow-slack

[potiuk]

Thanks for this, and sorry to close it.

Same situation as #70250: this fixes the datetime.date half of the _python_type_from_string type map, and #70249 — opened 22 July — fixes both datetime.date and datetime.datetime in one change, plus normalises the trailing Z the API emits and passes already-typed values through.

Worth being explicit that this PR and #70250 are complementary rather than duplicates of each other — each fixes one half. But #70249 subsumes both, so I'd rather land that one than take two partial fixes.

Closing in favour of #70249. Your iso_date_type and the test pinning --partition-date-gte were good calls — #70249 has the equivalent.

---

Drafted by an AI assistant and may contain mistakes — if you think this call is wrong, say so and the PR will be reopened; a human maintainer has the final word.

Drafted-by: Claude Code (Opus 5); reviewed by @potiuk before posting