> I'm still leary of supporting any form of DST. A proper DST
> implementation would need to have some conditional code to
> account for the datetime object passed into dst, and yet the
> version you have prototyped doesn't handle it.

No, any tzinfo implementation where utcoffset(dt) depends on dt is broken because once utcoffset starts to vary with time you can no longer determine a point in time from the local time alone. (In theory, a continuously increasing or decreasing in time utcoffset is an exception to this rule, but there is no practical use for those.)

This limitation is admitted in datetime.tzinfo documentation:

"""
Note that there are unavoidable subtleties twice per year in a tzinfo subclass accounting for both standard and daylight time, at the DST transition points. ... Applications that can’t bear such ambiguities should avoid using hybrid tzinfo subclasses; there are no ambiguities when using UTC, or any other fixed-offset tzinfo subclass (such as a class representing only EST (fixed offset -5 hours), or only EDT (fixed offset -4 hours)).
"""

(See three paragraphs above http://docs.python.org/dev/py3k/library/datetime.html#strftime-and-strptime-behavior)

In pytz, <http://pytz.sourceforge.net/#tzinfo-api>, tzinfo API is extended to add an is_dst flag to utcoffset(), tzname(), and dst() methods, but since datetime objects do not carry this flag, it is impossible for datetime module to pass this flag to timezone within datetime.datetime methods and datetime module does not know about this flag to begin with.

To add insult to injury, the extended API still does not solve all the problems: <http://pytz.sourceforge.net/#problems-with-localtime>.

> So a proper timezone supporting DST would still need to subclass
> any concrete class.

No, as I explained above, it is not possible to implement a "proper timezone."  I believe most of the frustration with the current tzinfo API stems from the fact that it is not implementable.   The correct interface to a timezone database should provide a mapping from (universal time, geographical location) to civil time there and then.  A common name for the timezone in use and information about DST being in effect is useful for interoperability but not strictly required.

This is what I implemented in my localtime() prototype in localtime.py (loosing DST information) and datetimeex.py (interoperable with POSIX timetupe based interfaces and pytz extended API).

Note that on systems supporting extended tm structure (with tm_zone and tm_gmtoff fields), it is possible to implement localtime() which will take advantage of the full historical timezone information available on the system.