ecerulm commented on a change in pull request #16631:
URL: https://github.com/apache/airflow/pull/16631#discussion_r658101143
##########
File path: tests/serialization/test_dag_serialization.py
##########
@@ -446,6 +447,26 @@ def validate_deserialized_task(
datetime(2019, 8, 1, tzinfo=timezone.utc),
),
(pendulum.datetime(2019, 8, 1, tz='UTC'), None,
pendulum.datetime(2019, 8, 1, tz='UTC')),
+ (
+ pendulum.parse("2019-08-01T00:00:00.000+00:00"),
+ None,
+ pendulum.parse("2019-08-01T00:00:00.000+00:00"),
+ ),
+ (
+ pendulum.parse("2019-08-01T00:00:00.000+01:30"),
+ None,
+ pendulum.parse("2019-08-01T00:00:00.000+01:30"),
+ ),
+ (
+ pendulum.datetime(2019, 8, 1, tz='Europe/Stockholm'),
+ None,
+ pendulum.datetime(2019, 8, 1, tz='Europe/Stockholm'),
+ ),
+ (
+ pendulum.datetime(2019, 8, 1, tz=FixedTimezone(3600)),
+ None,
+ pendulum.datetime(2019, 8, 1, tz=FixedTimezone(3600)),
+ ),
]
Review comment:
I can try but I really that will add some very pendulum-specific logic.
I mean, it will involve checking if this is a
`pendulum.tz.timezone.FixedTimezone` and serializing to int if so, there is no
"standard" good way of checking if a given `datetime.tzinfo` is a simple
timezone (fixed offset only) or a full fledged timezone (with arbitrarily
complex dst rules, etc).
In principle the user can provide a `datetime.tzinfo` of it's own with name
`RubenTZ` and that will fail the `pendulum.timezone('RubenTZ')` but doesn't
mean that we can just serialize to a fixedoffset (RubenTZ is much more complex)
What I'm trying to say is that is going to endup being very hackish anyway,
but in the serializing part instead of the deserializing part.
--
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.
For queries about this service, please contact Infrastructure at:
[email protected]
