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.

Author Alexandre.Zani
Recipients Alexander.Belopolsky, Alexandre.Zani, barry, belopolsky, djc, lemburg, r.david.murray
Date 2012-06-04.19:21:23
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1338837684.51.0.0473623533288.issue14908@psf.upfronthosting.co.za>
In-reply-to
Content
I'm still reading through the issue you mentioned. (It's a painful read I have to admit) One major obstacle seems to be that during the DST switch over, an hour gets repeated and so the datetime object is ambiguous. (are you on the first or second hour?) I would argue that it isn't a problem that this function needs to solve. The ambiguity isn't tied to the conversion. It's tied to the datetime object itself.

Let's add an optional parameter to specify the DST status, doc the pitfall and not worry overmuch about it.

Side note: Let me know if I misunderstood Alexander, but if I didn't this should be documented with the datetime object. Based upon my understanding, the datetime object is a bad choice if you care about that ambiguity. That's not really clear.
History
Date User Action Args
2012-06-04 19:21:24Alexandre.Zanisetrecipients: + Alexandre.Zani, lemburg, barry, belopolsky, djc, r.david.murray, Alexander.Belopolsky
2012-06-04 19:21:24Alexandre.Zanisetmessageid: <1338837684.51.0.0473623533288.issue14908@psf.upfronthosting.co.za>
2012-06-04 19:21:23Alexandre.Zanilinkissue14908 messages
2012-06-04 19:21:23Alexandre.Zanicreate