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 belopolsky
Recipients belopolsky, p-ganssle, tim.peters
Date 2016-11-03.19:31:14
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
Paul G at Github:

To be clear, I'm just saying that fromutc() goes from returning something meaningful (the correct date and time, with no indication of what side of the fold it's on) to something useless (an incorrect date and time) in the case where you're on the STD side of the divide. That change would restore the original behavior.

For most of the tzinfo implementations I'm providing (tzrange, tzwin, etc), there's no problem with an invariant standard time offset, so I'd prefer to fall back on the default algorithm in those cases.

Another advantage with using the standard algorithm as a starting point is that it all the type checking and such that's done in fromutc is done at that level, and I don't have to keep track of handling that.

All that said, it's not a huge deal either way.

Since it is not a big issue for you, I would rather not reopen this can of worms.  It may be better to return a clearly erroneous result on fold-aware tzinfos to push the developers like you in the right direction. :-)

After all, how much effort would it save for you in dateutil if you could reuse the base class fromutc?
Date User Action Args
2016-11-03 19:31:14belopolskysetrecipients: + belopolsky, tim.peters, p-ganssle
2016-11-03 19:31:14belopolskysetmessageid: <>
2016-11-03 19:31:14belopolskylinkissue28602 messages
2016-11-03 19:31:14belopolskycreate