Repository navigation
Conversation
|
All commit authors signed the Contributor License Agreement. |
bedevere-app
Bot
added
awaiting review
docs
Documentation build overview
25 files changed ·
|
| An object of type :class:`.time` or :class:`.datetime` may be aware or naive. | ||
|
|
||
| A :class:`.datetime` object ``d`` is aware if both of the following hold: | ||
| A :class:`.datetime` object ``d`` is aware if ``d.utcoffset()`` does not return |
There was a problem hiding this comment.
Can you please add references to the methods, you can put the proper target in <...> to keep the text as is.
I think this an improvement, the majority of readers likely care more about the practical test than underlying details. Any thoughts @pganssle ?
There was a problem hiding this comment.
This whole thing is actually a very odd definition if you think about it. In practice, for datetime, none of the major tzinfo implementations will return None for any datetime. Even if it did sometimes return None, that would be a very odd definition of naïve.
I think the reason for this is time objects, which get the same tzinfo objects attached to them, but when those have any transitions they are returning None, but it's also very odd to consider those times naïve just because you don't know what the offset is.
But I suppose that logically it does make sense to document it this way. (Though in practice it's probably much faster to check .tzinfo is None, so dt.tzinfo is None or dt.utcoffset() is None is more performant, though if that is someone's bottleneck I'm sure they will figure it out).
Summary
Simplifies the documentation for determining whether
datetimeandtimeobjects are aware or naive.Both objects'
utcoffset()methods already account for the presence of timezone information and whether the resulting UTC offset isNone. The updated wording explains this more directly.Issue
gh-160035
Verification
Doc/make.bat check— passed.python -m test test_datetime— passed (1,098 tests run, 106 skipped).