bolkedebruin commented on PR #34492: URL: https://github.com/apache/airflow/pull/34492#issuecomment-1727884891
> Initially I thought that it would be also a good idea to use reuse [serializer](https://github.com/apache/airflow/pull/34492#discussion_r1330748633) however there is one small but important thing. > > When you have timezone (subclass of [`tzinfo`](https://docs.python.org/3/library/datetime.html#datetime.tzinfo)) then we have a limited number of opportunity to extract exact timezone because this is depend on implementation, e.g. classes from `pendulum.tz.timezone` could store either in IANA timezone (`Timezone `) or offset from utc (`FixedTimezone`) and it's pretty logical that we only support Pendulum implementation. > > However in case if we work with datetime-naive and we don't know how to extract name (deatetime.timezone, zoneinfo, pytz and etc), we could always calculate exact offset to UTC by call [`utcoffset()`](https://docs.python.org/3/library/datetime.html#datetime.datetime.utcoffset) method and this value could be use in deserialisation to Pendulum Timezone > > So if we would like to create generic timezone extraction we could create this method in `airflow.utils.timezone` and extract depend of the input type `tzinfo` or `datetime.datetime` I'm not sure if I follow. We already convert naive dates to UTC (pendulum) datetimes. And we explicitly do not support other libraries than Pendulum since the integration of timezones into Airflow. So I don't think your second case makes sense? Refactoring into `airflow.utils.timezone` does make sense. We would end up with a wrapper that basically does the same as FixedTimezone and Timezone -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
