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
_______________________________________________ Datetime-SIG mailing list [email protected] https://mail.python.org/mailman/listinfo/datetime-sig The PSF Code of Conduct applies to this mailing list: https://www.python.org/psf/codeofconduct/
