timezone has now moved to a new location

[o-nikolas]

Wrap import in a try/catch to support older versions of airflow, otherwise import from task sdk

Previous to this change, I was receiving pre-commit errors when modifying executor modules:

providers/amazon/src/airflow/providers/amazon/aws/executors/aws_lambda/lambda_executor.py:46: error:
Module "airflow.utils" has no attribute "timezone"  [attr-defined]
    from airflow.utils import timezone
    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
providers/amazon/tests/unit/amazon/aws/executors/aws_lambda/test_lambda_executor.py:34: error:
Module "airflow.utils" has no attribute "timezone"  [attr-defined]
    from airflow.utils import timezone
    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Found 2 errors in 2 files (checked 3 source files)
exit status 1
Error 1 returned

---

^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named {pr_number}.significant.rst or {issue_number}.significant.rst, in airflow-core/newsfragments.

[o-nikolas]

@ashb

I was looking at some of the changes you made in #53149, I see in some places the try/catch import from task sdk is used and in others and import from __shared. Is the try/catch import from sdk the correct approach for a provider use case like this?

[uranusjr]

I believe provider code should generally import from sdk (since that’s the public API)

[o-nikolas]

I believe provider code should generally import from sdk (since that’s the public API)

I agree, generally. But providers use much more internal pieces of airflow than what a user would in their Dags alone. So they're not playing by the exact same rules there. But in this case, agreed, import from sdk makes sense.

[ashb]

But providers use much more internal pieces of airflow than what a user would in their Dags alone

Going forward I would like that not to be the case -- and providers can only access things in the public API -- custom operator or provider or python task in DAG file should be on the same level.

[ashb]

Thank you for picking this up, I had forgotten to go and do this for all the providers after my PR landed 🤦🏻 (I didn't want providers and core in the same PR)