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 ajaksu2, belopolsky, brett.cannon, daniel.urban, doerwalter, eric.araujo, ggenellina, kawai, l0nwlf, mark.dickinson, pitrou, r.david.murray, rafe, techtonik, vstinner
Date 2010-06-04.16:05:44
SpamBayes Score 8.4384664e-07
Marked as misclassified No
Message-id <>
> 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

In pytz, <>, 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: <>.

> 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 (loosing DST information) and (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.
Date User Action Args
2010-06-04 16:05:47belopolskysetrecipients: + belopolsky, doerwalter, brett.cannon, mark.dickinson, ggenellina, pitrou, vstinner, techtonik, ajaksu2, kawai, eric.araujo, r.david.murray, rafe, daniel.urban, l0nwlf
2010-06-04 16:05:47belopolskysetmessageid: <>
2010-06-04 16:05:45belopolskylinkissue5094 messages
2010-06-04 16:05:44belopolskycreate