Refactor Opensearch log formatter to use timezone.from_timestamp and export it in Task SDK

[23tae]

Description

This PR refactors the OpensearchJSONFormatter to use the standard Airflow timezone.from_timestamp utility, addressing a TODO in the codebase.

Key changes

• Exported from_timestamp in airflow.sdk.timezone to make it part of the public Task SDK API, ensuring consistency across the project.
• Implemented version-based compatibility logic in the Opensearch provider. The formatter now uses the new timezone.from_timestamp on Airflow 3.3.0+ and maintains backward compatibility by falling back to the original pendulum/datetime logic on older Airflow 3.x releases (e.g., 3.0.6, 3.2.1).

Verification Results

I have verified the changes using both prek (ruff) and breeze (standardized Docker environment).

• Unit Tests (Breeze): Passed (3 tests)
• Static Checks (Prek): Passed (ruff)

---

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

• Yes

Generated-by: Antigravity following the guidelines

Please review this refactor.
cc. @choo121600 @noeunkim

---

• 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.

[SameerMesiah97]

There's a contradiction between the #TODO and what you are doing in this PR. I have left a comment.

[SameerMesiah97]

I am not sure why you are importing timezone from task sdk when the intention was to use timezone from airflow.utils.

[23tae]

Thanks for the review.
I initially tried to follow the TODO and use airflow.utils.timezone, but the linter (Ruff) gave an error (TID251) and recommended airflow.sdk.timezone instead. I also saw that other files in this provider were already using the Task SDK, so I followed that pattern.
I’ve also moved the import inside the block to fix the ImportError in CI. Let me know if you’d still like me to revert it to utils.

[SameerMesiah97]

Thanks for the review. I initially tried to follow the TODO and use airflow.utils.timezone, but the linter (Ruff) gave an error (TID251) and recommended airflow.sdk.timezone instead. I also saw that other files in this provider were already using the Task SDK, so I followed that pattern. I’ve also moved the import inside the block to fix the ImportError in CI. Let me know if you’d still like me to revert it to utils.

Okay. That makes sense. Thanks for clarifying that.

[SameerMesiah97]

Is there no way to avoid expanding the API surface of the task SDK? It seems overkill for a simple provider PR. Maybe you can try using datetime?

[23tae]

Thanks for the suggestion.
I tried to use existing SDK utilities like coerce_datetime to avoid the expansion, but I noticed there's already a linter rule in pyproject.toml (line 886) that explicitly recommends airflow.sdk.timezone.from_timestamp over pendulum.from_timestamp.
It seems the intention was for providers to use this function, but it was just missing from the SDK's public __all__. So I think adding it there is the right fix rather than working around it.

[eladkal]

cc @Owen-CH-Leung can you help review this PR?

@23tae can you confirm if the issue affect only Opensearch and not also Elasticsearch?

[23tae]

@eladkal Yes, I confirmed that the exact same legacy pendulum usage and TODO exist in the Elasticsearch provider (es_json_formatter.py).
Should I open a separate PR to keep the changelogs independent, or just add a commit here?
Let me know how you'd like me to proceed.

[eladkal]

@eladkal Yes, I confirmed that the exact same legacy pendulum usage and TODO exist in the Elasticsearch provider (es_json_formatter.py). Should I open a separate PR to keep the changelogs independent, or just add a commit here? Let me know how you'd like me to proceed.

We can have seperate PR for elastic that we will review in parallel to this one