[issue13277] tzinfo subclasses information
New submission from Senthil Kumaran <senthil@uthcode.com>: 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. ---------- assignee: docs@python messages: 146501 nosy: docs@python, orsenthil priority: normal severity: normal stage: needs patch status: open title: tzinfo subclasses information type: behavior _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue13277> _______________________________________
Changes by Petri Lehtinen <petri@digip.org>: ---------- nosy: +petri.lehtinen _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue13277> _______________________________________
Changes by Ezio Melotti <ezio.melotti@gmail.com>: ---------- nosy: +belopolsky, lemburg _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue13277> _______________________________________
Mark Lawrence added the comment: I don't understand the implications of timezone stuff at all so can a guru on the subject please comment on this. ---------- nosy: +BreamoreBoy versions: +Python 2.7, Python 3.4, Python 3.5 _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue13277> _______________________________________
Alexander Belopolsky added the comment: 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. ---------- components: +Documentation nosy: +tim.peters _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue13277> _______________________________________
Change by Mark Lawrence <breamoreboy@gmail.com>: ---------- nosy: -BreamoreBoy _______________________________________ Python tracker <report@bugs.python.org> <https://bugs.python.org/issue13277> _______________________________________
participants (5)
-
Alexander Belopolsky -
Ezio Melotti
-
Mark Lawrence
-
Petri Lehtinen
-
Senthil Kumaran