Appreciate the advice, I have to admit that these edge cases seem rare enough that they haven't been a priority for me (I'm still trying to wrap up a release that doesn't occasionally break the parser for certain strings on the 29th-31st of every month, for example).
Much to think about hate, I like that zdump idea as a method for test discovery. On Sep 18, 2015 3:01 PM, "Tim Peters" <[email protected]> wrote: > [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/
