Fix ambiguous parse

[pganssle]

Should fix #318 in favor of #319. I don't 100% love special-casing UTC like this, but I think that's the only exception here and anything else would lead to even weirder edge cases.

[pganssle]

Ping @JordonPhillips

[pganssle]

@jbrockmendel Any thoughts?

[jbrockmendel]

Will look this over now; sorry it got lost in the inbox for a bit.

[jbrockmendel]

Not all that familiar with the fold method, need to do some reading on it. But that aside, it looks like the point of this feature is to replace tzinfo=tzlocal() with tzinfo=explicitly_named_tzinfo().

_assign_tzname could use a brief docstring, but it's a nice tight method. +1

LGTM.

[pganssle]

@jbrockmendel Not quite. fold is an attribute for distinguishing between two otherwise identical dates, e.g. 1:30 AM EDT vs 1:30 AM EST during an EDT->EST transition. So:

'2011-11-06T01:30 EDT'
'2011-11-06T01:30 EST'

These two things are unambiguous representations (assuming you have the context to know that EST and EDT are both representations of the Eastern time zone) of the same naive datetime. With Python's time zone model, the tz offset is a function of the naive datetime portion, so for dates like the above differing only in their offset, there was no way to represent the difference with the same tzinfo object. In Python 3.6, they introduced fold, so you can represent those two, respectively, as:

datetime(2011, 11, 6, 1, 30, fold=0, tzinfo=Eastern)
datetime(2011, 11, 6, 1, 30, fold=1, tzinfo=Eastern)

In the old behavior, it used to be that we'd see EST or EDT, find that those were aliases for the local time zone name, and assign tzlocal(), but of course we didn't assign the fold component, because it didn't exist until recently. This patch just checks to see if the tzname doesn't match the string token but a datetime with fold=1 set would match the string token, that we set fold=1.

At this point, no matter what happens, you're still getting tzlocal() (except in the weird edge case of Europe/London, where their winter time is an alias for UTC, which was causing some problems similar to this), the only difference is we're now respecting explicitly stated DST preferences in the case of ambiguous times.

[JordonPhillips]

Confirmed this works, thanks!