Make web logs timestamps DST aware
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
- [X] I think the code is well written
- [X] Unit tests for the changes exist
- [X] Documentation reflects the changes
- [X] If you provide code modification, please add yourself to
CONTRIBUTORS.txt- The format is <Name> <Surname>.
- Please keep alphabetical order, the file is sorted by names.
- [X] Add a new news fragment into the
CHANGES/folder-
name 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 an improper 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 breaking changes 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 build process..packaging: Notes for downstreams about unobvious side effects and 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 above categories.
-
Make sure to use full sentences with correct case and punctuation, for example:
Fixed issue with non-ascii contents in doctest text files -- by :user:`contributor-gh-handle`.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.
-
Codecov Report
:white_check_mark: All modified and coverable lines are covered by tests.
:white_check_mark: Project coverage is 98.80%. Comparing base (281479a) to head (d7319a7).
:white_check_mark: All tests successful. No failed tests found.
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
| Flag | Coverage Δ | |
|---|---|---|
| CI-GHA | 98.67% <100.00%> (+<0.01%) |
:arrow_up: |
| OS-Linux | 98.40% <100.00%> (+<0.01%) |
:arrow_up: |
| OS-Windows | 96.73% <100.00%> (-0.01%) |
:arrow_down: |
| OS-macOS | 97.62% <100.00%> (+<0.01%) |
:arrow_up: |
| Py-3.10.11 | 97.14% <100.00%> (-0.01%) |
:arrow_down: |
| Py-3.10.18 | 97.64% <100.00%> (-0.01%) |
:arrow_down: |
| Py-3.11.13 | 97.83% <100.00%> (+<0.01%) |
:arrow_up: |
| Py-3.11.9 | 97.33% <100.00%> (-0.01%) |
:arrow_down: |
| Py-3.12.10 | 97.44% <100.00%> (-0.01%) |
:arrow_down: |
| Py-3.12.11 | 97.94% <100.00%> (+<0.01%) |
:arrow_up: |
| Py-3.13.7 | 98.19% <100.00%> (+<0.01%) |
:arrow_up: |
| Py-3.14.0-rc.3 | 98.13% <100.00%> (-0.02%) |
:arrow_down: |
| Py-3.14.0-rc.3t | 97.20% <100.00%> (-0.01%) |
:arrow_down: |
| Py-3.9.13 | 97.02% <100.00%> (-0.01%) |
:arrow_down: |
| Py-3.9.23 | 97.52% <100.00%> (+<0.01%) |
:arrow_up: |
| Py-pypy3.9.19-7.3.16 | 90.35% <20.00%> (-2.90%) |
:arrow_down: |
| VM-macos | 97.62% <100.00%> (+<0.01%) |
:arrow_up: |
| VM-ubuntu | 98.40% <100.00%> (+<0.01%) |
:arrow_up: |
| VM-windows | 96.73% <100.00%> (-0.01%) |
:arrow_down: |
Flags with carried forward coverage won't be shown. Click here to find out more.
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
CodSpeed Performance Report
Merging #11557 will not alter performance
Comparing sgaist:11283-make-weblog-dst-aware (0e6e313) with master (a7c21bb)
Summary
✅ 59 untouched
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.
@Dreamsorcerer I'll try, just need to check how to use freezegun.
@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.
@Dreamsorcerer I have modified the implementation as using freezgun unearthed an interesting issue with tm_gmtoff: it can be empty.
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.