This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: tzinfo subclasses information
Type: behavior Stage: needs patch
Components: Documentation Versions: Python 3.4, Python 3.5, Python 2.7
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: docs@python Nosy List: belopolsky, docs@python, lemburg, orsenthil, petri.lehtinen, tim.peters
Priority: normal Keywords:

Created on 2011-10-27 16:40 by orsenthil, last changed 2022-04-11 14:57 by admin.

Messages (3)
msg146501 - (view) Author: Senthil Kumaran (orsenthil) * (Python committer) Date: 2011-10-27 16:40
This was in the docs mailing list, not translated to bug report

Paul Koning wrote:

Section 8.1.6 of the library manual talks about utcoffset(dt)-dst(dt) as the "standard offset" and says that this should not depend on the date or +time but only on the location.

This is not true as there cases were certain locations changed the time offsets as per their convenience. 

It is either a doc fix to remove that sentence if the datetime.astimezone does not depend upon utcoffset(dt)-dst(dt), or if it does, then it is a code fix.
msg221767 - (view) Author: Mark Lawrence (BreamoreBoy) * Date: 2014-06-28 02:05
I don't understand the implications of timezone stuff at all so can a guru on the subject please comment on this.
msg221769 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2014-06-28 02:26
I would say this is a doc issue.  There are some tzinfo algorithms that depend on utcoffset(dt)-dst(dt) being invariant, but this is the part of datetime library that I have never fully understood.

What I do understand is that conversion from local time to UTC or another timezone is a hard and not always solvable problem (some local times are invalid and some are ambiguous).  (If some local government decides that 00:59 should be followed by 02:00, one is hard pressed to figure out what 01:30 local time is in UTC.)

I think documentation should emphasize the fact that the standard library only supports fixed offset timezones.  It is up to the application programmer or a 3rd party library to figure out which fixed offset is appropriate in which case.
History
Date User Action Args
2022-04-11 14:57:23adminsetgithub: 57486
2019-03-16 00:00:55BreamoreBoysetnosy: - BreamoreBoy
2014-06-28 02:26:13belopolskysetnosy: + tim.peters
messages: + msg221769
components: + Documentation
2014-06-28 02:05:40BreamoreBoysetnosy: + BreamoreBoy

messages: + msg221767
versions: + Python 2.7, Python 3.4, Python 3.5
2011-10-30 13:01:53ezio.melottisetnosy: + lemburg, belopolsky
2011-10-28 05:25:37petri.lehtinensetnosy: + petri.lehtinen
2011-10-27 16:40:06orsenthilcreate