[Alex] > ... > I suspect dateutil has problems that are not limited to ambiguous > datetimes in some IANA time zones.
For pytz, Stuart said he ran zdump across all zones in the database, to drive exhaustive tests of all transition instants in every zone. That's an excellent idea :-) I strongly suspect dateutil will get some cases wrong simply because it's paying attention to the gmt/std/wall indicators in tzfiles. Those have no meaning for anything a tzinfo is trying to accomplish - it's an "attractive nuisance" that they're even stored in a tzfile. To convert transition times from UTC to local times (as dateutil appears to want to do), it should simply add the current total UTC offset, ignoring the gmt/std/wall indicators entirely. All transition times in tzfiles are recorded in UTC, regardless of what the gmt/std/wall indicators say. That won't make any difference for "most" zones because it just so happens that the "wall" indicator is set for most transitions and the "std" indicator is not (reflecting that most zoneinfo _source_ files record DST transition points in local wall-clock time). An exhaustive test would stumble into the exceptions. The way to fix broken cases discovered this way is to just ignore gmt/std/wall (better, seek over 'em when reading the file - they're useless). _______________________________________________ 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/
