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:49:50
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
> I can't think of a single actual downside to this change - all it does is preserve the original behavior of `fromutc()`.

You've got me on the fence here.  If what you are saying is correct, it would make sense to make this change and better do it before 3.6 is out, but it would take me some effort to convince myself that an implementation that reuses patched fromutc() is indeed correct.

Why don't you implement tzrange.fromutc() in terms of say tzrange.simple_fromutc() which is your own patched version of tzinfo.fromutc().  If this passes your tests and is simpler than a straightforward fromutc() that does not have to look at tzinfo through the needle hole of utcoffset()/dst() pair but knows the internals of your timezone object, we can consider promoting your simple_fromutc() to default stdlib implementation.

Alternatively, you can just convince Tim. :-)
Date User Action Args
2016-11-03 19:49:50belopolskysetrecipients: + belopolsky, tim.peters, p-ganssle
2016-11-03 19:49:50belopolskysetmessageid: <>
2016-11-03 19:49:50belopolskylinkissue28602 messages
2016-11-03 19:49:50belopolskycreate