notatallshaw-gts commented on issue #19450:
URL: https://github.com/apache/airflow/issues/19450#issuecomment-1548451405
> `astimezone`
I foresee three main hurdles with converting from `in_tz` to `astimezone`:
1. `astimezone` only takes a `tzinfo` subclass, whereas `in_tz` will coerces
a string, which leads to my next most common use case:
```
{{ data_interval_end.in_tz("America/New_York").format('YYYY_MM_DD') }}
```
2. Useful timezones like "America/New_York" are not supported in the
standard library until Python 3.9 with `zoneinfo`
3. I have a feeling that for such a large application and datetime sensitive
application like Airflow it's going to discover lots or weird edge cases (e.g.
https://news.ycombinator.com/item?id=35916074) in the standard library as it's
so relatively recent to the standard library and the larger Python ecosystem
has historically relied on third party libraries, but hopefully the test suite
is ready for it
> `stftime`
There is definitely fractional second formatting using `.format` that cannot
be expressed using purely `stftime` alone:
https://pendulum.eustace.io/docs/#tokens
I'm not saying migrating moving off Pendulum will be impossible, just
raising that for at least some users it will be painful.
--
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]
