> I am aware of that.  In fact, some of the draft versions of PEP 495 implementation did contain such code.  The problem is that any such tz.fromutc() implementation would necessarily change the behavior of the old programs.

This I'm not sure about - the implementation I've provided gives the same answer for any program that pays no attention to `fold`, because I'm relying on `utcoffset` and `dst`'s reaction to a change in fold. Any code that's not explicitly handling fold will give the same answer as it always has.

> Moreover, any implementation of tz.fromutc() in terms of tz.utcoffset() is more complicated and less efficient than code that he's direct access to a database of transition times.

While true, that does not argue in favor of having a version of `fromutc` that doesn't respect `fold`, because anyone looking for a more efficient implementation will have to reimplement `fromutc` anyway if necessary.

Another argument in favor of having `fromutc` respect fold by default is that it makes it very simple to support fold, particularly for people who aren't optimizing for speed. As it is now, you have to duplicate a lot of fold-handling and transition lookup logic in both `fromutc` and `utcoffset` / `dst`, because they are getting the same information but they are not implemented in terms of one another (and it's not even amazingly easy to write a function that factors out the common code). That's more code to write and maintain and test.

At the end of the day, almost everyone who cares about efficiency will use dateutil or pytz for their application, and dateutil and pytz can and do re-implement fromutc when appropriate - though there are still some `dateutil` tzinfo subclasses where this would be *more* efficient than what's there now. I don't see why the perfect has to be the enemy of the good here, though; having fold support in `fromutc` is a net benefit for anyone using `fromutc` and for adoption of PEP 495 in a wider context.