[Datetime-SIG] Computing .dst() as a timedelta

[Alexander Belopolsky]

The datetime.dst() and its namesake tzinfo.dst() [1] methods are required
to return a timedelta object that represents a quantity added to standard
time in a spring-forward transition.

As explained in documentation, the dst() value is already incorporated in
the value returned by utcoffset() and is not needed in typical
calculations.  Therefore, it is not surprising that both dateutil and pytz
get it wrong in some cases. [2,3]

While pytz does slightly better than dateutil, it looks like it may not be
possible to derive the correct value of dst() from the compiled binary
tzfiles alone in all cases.

The problematic cases are transitions that involve a simultaneous change in
standard time and a DST transition.  For example, Portugal switching from
CET to WEST in 1996. [2]

While the "SAVE" amount can be found in the raw tzdist files, this
information is lost when the raw files are compiled.  The transition
information includes only the full new UTC offset and a boolean isdst
flag.  If the transition is a pure DST transition, then dst() is just the
difference between the new UTC offset and the old, but if the standard time
offset changes at the time of the DST transition, there is no information
in the binary tzfile to split the full difference into standard time change
and DST adjustment.

Unless I miss something, it looks like a high-quality tzinfo implementation
should extract the "SAVE" information from the raw files.

[1]: https://docs.python.org/3/library/datetime.html#datetime.tzinfo.dst
[2]: https://github.com/dateutil/dateutil/issues/128
[3]: https://bugs.launchpad.net/pytz/+bug/1497619
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/datetime-sig/attachments/20150919/e0aaaae2/attachment.html>