[Datetime-SIG] Adding PEP 495 support to dateutil

[Paul Ganssle]

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" <tim.peters at gmail.com> 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).
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/datetime-sig/attachments/20150918/a9c48948/attachment-0001.html>