Fix ExternalTaskSensor log timezone

[reachsrinivaschennupati-tech]

Summary

Make ExternalTaskSensor poke logs display external logical dates in Airflow's configured timezone.

Problem

ExternalTaskSensor logs currently serialize the external logical date directly from the stored filter value. This can make poke logs harder to read in deployments where Airflow is configured with a non-UTC timezone.

Solution

• Add a log-only serializer that converts external logical dates to settings.TIMEZONE.
• Use the timezone-adjusted value in poke log messages for DAG, task group, and task checks.
• Keep external_dates_filter unchanged so listeners and integrations continue to receive the original serialized logical date.
• Added focused unit coverage for configured-timezone log serialization.

Validation

• Added focused unit coverage for ExternalTaskSensor._serialize_dttm_filter_for_log.

closes: #69657

[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

[reachsrinivaschennupati-tech]

Hi maintainers, this PR is ready for review when you have a chance.

The change is intentionally log-only: ExternalTaskSensor keeps the original external_dates_filter behavior for listeners/integrations, while poke log messages serialize the external logical date in Airflow's configured timezone for readability.

Validation noted in the PR:

• Focused unit coverage for ExternalTaskSensor._serialize_dttm_filter_for_log.

Happy to adjust naming or test placement if there is a preferred provider-standard convention.

[reachsrinivaschennupati-tech]

Hi Maintainers, this PR is ready for review when you have a chance, please review and trigger the CI workflow.

[dhkim1920]

Thanks for working on this.

I had also started looking into a fix for #69657 and noticed two details that may be worth considering before review:

1. It may be clearer to retain the original external logical_date representation in the poke log and show the configured-timezone rendering alongside it, rather than replacing the logged value entirely.

This would preserve the canonical value for correlation and debugging while still making the configured local time immediately readable.

For example:

Poking for DAG 'example_external_dag' on logical_date 2026-07-06T21:00:00+00:00 (default timezone: 2026-07-07T06:00:00+09:00) ...

2. The new test is currently located in TestExternalTaskSensorV2, which is skipped when running against Airflow 3. It would be useful to add equivalent coverage to the Airflow 3 test path so that the changed poke log is exercised on the version targeted by this PR.

# tests\unit\standard\sensors\test_external_task_sensor.py TestExternalTaskSensorV2: line 135
@pytest.mark.skipif(AIRFLOW_V_3_0_PLUS, reason="Different test for v3.0+")

I have a local branch implementing this approach, but I would prefer not to open a near-duplicate PR unless the maintainers would like to evaluate it separately.

[reachsrinivaschennupati-tech]

@dhkim1920 Thanks for your suggestions, I have added your recommended changes into this PR.