Author belopolsky
Recipients BreamoreBoy, belopolsky, docs@python, lemburg, orsenthil, petri.lehtinen, tim.peters
Date 2014-06-28.02:26:13
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1403922373.99.0.523906103891.issue13277@psf.upfronthosting.co.za>
In-reply-to
Content
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
2014-06-28 02:26:14belopolskysetrecipients: + belopolsky, lemburg, tim.peters, orsenthil, docs@python, BreamoreBoy, petri.lehtinen
2014-06-28 02:26:13belopolskysetmessageid: <1403922373.99.0.523906103891.issue13277@psf.upfronthosting.co.za>
2014-06-28 02:26:13belopolskylinkissue13277 messages
2014-06-28 02:26:13belopolskycreate