[Datetime-SIG] Adding PEP 495 support to dateutil
paul at ganssle.io
Fri Sep 18 21:16:20 CEST 2015
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
On Sep 18, 2015 3:01 PM, "Tim Peters" <tim.peters at gmail.com> wrote:
> > ...
> > 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).
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Datetime-SIG