Deprecate naive datetime in StreamResponse.last_modified setter#13047
Deprecate naive datetime in StreamResponse.last_modified setter#13047amitmishra11 wants to merge 1 commit into
Conversation
Passing a naive datetime to StreamResponse.last_modified is ambiguous because datetime.utctimetuple() on a naive datetime returns the local fields unchanged, which then gets labelled as GMT in the header. This means datetime.now() (local time) would produce an incorrect Last-Modified header. Emit a DeprecationWarning so users are guided to use timezone-aware datetimes such as datetime.now(datetime.timezone.utc). Fixes aio-libs#5304
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #13047 +/- ##
=======================================
Coverage 98.96% 98.96%
=======================================
Files 131 131
Lines 48156 48163 +7
Branches 2499 2500 +1
=======================================
+ Hits 47656 47663 +7
Misses 376 376
Partials 124 124
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. |
Merging this PR will not alter performance
Comparing Footnotes
|
What do these changes do?
Emit a
DeprecationWarningwhen a naivedatetime.datetimeis passedto
StreamResponse.last_modified. Previously, naive datetimes weresilently accepted, but
utctimetuple()on a naive datetime returns thelocal time fields unchanged, which then gets labelled as GMT in the
Last-ModifiedHTTP header. This means that callingresp.last_modified = datetime.now()(which returns local time) wouldproduce an incorrect header value -- the local time would be stored
verbatim as if it were UTC.
The fix adds a clear deprecation warning directing users to timezone-aware
datetimes (e.g.
datetime.now(datetime.timezone.utc)).Are there changes in behavior for the user?
Yes: passing a naive
datetimenow emits aDeprecationWarning. Theactual value stored in the header is unchanged from the previous
behaviour. A future release can raise a
TypeErrororValueErrorfornaive datetimes once the deprecation period has elapsed.
Is it a substantial burden for the maintainers to support this?
No. It is a one-line guard plus a warning in one setter, with a single
new test. The warning text is self-explanatory and points directly to
the fix.
Related issue number
Fixes #5304
Checklist
CHANGES/folderTest output
Drafted with Claude Sonnet 4.6; reviewed by amitmishra11.