Make web logs timestamps DST aware#11557
Conversation
This is done using the tm_gmtoff value rather than the static timezone information.
psf-chronographer
bot
added
the
bot:chronographer:provided
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #11557 +/- ##
==========================================
- Coverage 98.80% 98.80% -0.01%
==========================================
Files 127 127
Lines 43380 43383 +3
Branches 2326 2326
==========================================
+ Hits 42861 42863 +2
Misses 370 370
- Partials 149 150 +1
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
CodSpeed Performance ReportMerging #11557 will not alter performanceComparing Summary
|
webknjaz
left a comment
webknjaz
left a comment
There was a problem hiding this comment.
Can we have a regression test showing that DST is taken into account?
We have freezegun installed for tests, so we could use that to write a test dated in DST and one out of DST. |
|
If you have time to finish this off by tomorrow, I'll get it included in the 3.13 release. |
Co-authored-by: 🇺🇦 Sviatoslav Sydorenko (Святослав Сидоренко) <[email protected]>
|
@Dreamsorcerer I'll try, just need to check how to use freezegun. |
In test_cookiejar.py, we just use the context manager to set the date. |
localtime does not guarantee to of have a valid tm_gmtoff.
|
@Dreamsorcerer I have modified the implementation as using freezgun unearthed an interesting issue with I added a test to check that DST is reflected however I have not been able to make it work as I wanted with regard to adjusting the hour. |
Dreamsorcerer
added
the
backport-3.13
Dreamsorcerer
removed
the
backport-3.13
4 participants
What do these changes do?
Make web logs timestamps DST aware using the tm_gmtoff value rather than the static timezone information.
Are there changes in behavior for the user?
There might be a jump in timestamps where DST changes
Is it a substantial burden for the maintainers to support this?
There should be no burden for maintainers as there is no new code.
Related issue number
Fixes #11283
Checklist
CONTRIBUTORS.txtCHANGES/foldername it
<issue_or_pr_num>.<type>.rst(e.g.588.bugfix.rst)if you don't have an issue number, change it to the pull request
number after creating the PR
.bugfix: A bug fix for something the maintainers deemed animproper undesired behavior that got corrected to match
pre-agreed expectations.
.feature: A new behavior, public APIs. That sort of stuff..deprecation: A declaration of future API removals and breakingchanges in behavior.
.breaking: When something public is removed in a breaking way.Could be deprecated in an earlier release.
.doc: Notable updates to the documentation structure or buildprocess.
.packaging: Notes for downstreams about unobvious side effectsand tooling. Changes in the test invocation considerations and
runtime assumptions.
.contrib: Stuff that affects the contributor experience. e.g.Running tests, building the docs, setting up the development
environment.
.misc: Changes that are hard to assign to any of the abovecategories.
Make sure to use full sentences with correct case and punctuation,
for example:
Use the past tense or the present tense a non-imperative mood,
referring to what's changed compared to the last released version
of this project.