Convert internal timestamps to TZ-aware, treat user-provided TZ-naive ones as UTC #1068
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.
A few places inside Kopf were using TZ-naive timestamps internally:
Since
datetime.datetime.utcnow()
is deprecated in Python 3.12, we have to switch to TZ-aware "now" timestamps, and convert the rest for the ability to compare (Python cannot compare TZ-aware to TZ-naive).This PR ensures that all internal timestamps are TZ-aware. All user-provided TZ-naive timestamps are treated as UTC for comparison (but stored "as is").
The timestamps provided by Kubernetes API & Kubernetes resources were always parsed as TZ-aware, so this should not cause any spike in K8s API activity for reformatting the timestamps. And even if hypothetically happens to do that, this change only applies to Kopf's own "progression" timestamps, so this only affects the handlers that are still in progress/retrying, not the final stable state of resources.