-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove uses of utcnow
in non-vendored code
#12006
Merged
Merged
Changes from all commits
Commits
Show all changes
4 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
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
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1 @@ | ||
Removed uses of ``datetime.datetime.utcnow`` from non-vendored code. |
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
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
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
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does
fromisoformat
support a trailing "Z" meaning UTC in Python versions back to 3.7? Because we need to be able to read older versions of the state file. I know recent Pythons support the Z, but I don't have easy access to 3.7 to test that version.(Should we include a test that uses the old format, to confirm we don't break it? I'm ambivalent, because on the one hand, the test will only be relevant for a limited time, but on the other hand, it would check this compatibility point).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No. All versions of Python with a
.fromisoformat
will parse any valid output of.isoformat
, but I think 3.11 is when we added the ability to parse arbitrary ISO formats. As I explicitly mentioned in the commit message and in the description of the PR, my assumption was that no one would care about breaking old state files, since they are basically ephemeral anyway. From my testing, the result seemed to be that you get a warning about failing to read the state file.Should be easy enough to adapt with a fallback in the event of a failure to parse the date, or by having
pip
explicitly check the version in the old state file and either determine the parsing algorithm based on that or just invalidate all state files from other versions ofpip
(or outside some range or something).I don't think there's anything that can be done about the situation where someone generates a state file with the latest version of
pip
, then downgrades to an earlier version. Might be good to put an upper limit cap in place now just so that's not a concern in the future if you want to make other backwards-incompatible changes to the state files.Also, this change to the format is not really that important, it's just a slightly cleaner way to do things IMO. We could also make the
utcnow
-related changes without any of the changes to the state file.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, sorry - I was reading the code wrongly. This is just "do we need to refresh the state because it's over 7 days old?" So we can simply return
None
(saying that we need to refresh the state) if we hit a parse error. So it's not as big a problem as I was implying. I do think that trapping parse errors is worthwhile, now we're not controlling the serialisation format explicitly.