Stop serializing timezone-naive datetime as a timezone-aware datetime with UTC tz #36379
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
hussein-awala
requested review from
kaxil,
ashb and
bolkedebruin
as code owners
|
I really am not a fan of naive datetimes. They just don't make sense as they only exist subjectively. But that being said I think the change is fine and we should aim for integrity. |
bolkedebruin
approved these changes
Dec 25, 2023
68 tasks
abhishekbhakat
pushed a commit
to abhishekbhakat/my_airflow
that referenced
this pull request
Mar 5, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
related: #36363
Currently, the timezone-naive datetimes are serialized as timezone-aware dateimes with a timezone UTC, which makes the deserialized values different from the original ones. This PR stops this conversion and serializes the provided datetime as it is.
It's also backward compatible, where the serialized values will be deserialized just like before this change, but it will avoid some unexpected results like the issue explained in #36363.
@bolkedebruin Is there any specific reason for this conversion?