Add+collect tests for tzinfos input types, fix missed case of invalid…

[jbrockmendel]

Implement tests for types of inputs that can be passed as tzinfos (two of these are moved from further down in the file, the rest ported from downstream). Fixes the case where something bizarre is passed like tzinfos={"UTC": something_totally_invalid} which at the moment raises UnboundLocalError instead of TypeError

[pganssle]

Minor changes here, and this also needs a changelog (in the end I'm probably going to do a rollup of this in the next release to merge them into one big "Added a ton of tests. Patches by @jbrockmendel (gh prs #x, #y, #z)" so they can be pretty terse.

[jbrockmendel]

I'm travelling the next couple days, so may not get around to this until Wednesday. In the interim, can we merge the other two?

[pganssle]

@jbrockmendel I merged #892, but I think #894 is still blocked on changes from you. If you want I can make the changes myself and merge that one.

[jbrockmendel]

I think the requested change here is just adding assert res.tzinfo is expected.tzinfo where appropriate. I'm skipping that for the case where both are None. That leaves test_valid_tzinfo_tzinfo_input, test_valid_tzinfo_callable_input where that passes and test_valid_tzinfo_unicode_input where that assertion fails since that assertion amounts to tz.tzstr('UTC+0') is tz.UTC. I'm leaving that assertion out in the newest commit.

[jbrockmendel]

@pganssle gentle ping. I think this is the last of my test-refactoring PRs.

Also definitely-ready is gfyoung's #881. I definitely don't want to merge any of my own PRs, but would be comfortable taking on merge responsibilities for things like that.

[pganssle]

@jbrockmendel Sorry about all the delays. I'll review again today or tomorrow. Assuming any changes I might want are sufficiently simple, I'll just push them directly to your branch and merge rather than bother you with another round of addressing review comments.

[pganssle]

@jbrockmendel I've rebased this and unified the "check if equal + check if tzinfo is identical" logic into a common function, but looking at it, I think I misunderstood the xfail test:

    def test_valid_tzinfo_int_input(self):
        dstr = "2014 January 19 09:00 UTC"
        tzinfos = {u"UTC": -28800}
        expected = datetime(2014, 1, 19, 9, tzinfo=tz.UTC)
        res = parse(dstr, tzinfos=tzinfos)
        self.assert_equal_same_tz(res, expected)

The current behavior is that tz.tzoffset("UTC", -28800) gets attached to the result, which seems like the right thing to do, since specifying UTC in tzinfos is more explicit than an automatic mapping of "UTC" to tz.UTC.

I'll note that the fact that tzinfos can override what "UTC" gets parsed to also enables you to do things like tzinfos={"UTC": datetime.timezone.utc}, which could be very useful for people who want to use the standard library's objects.

If you agree that we should keep the current behavior, I'll adjust the final test appropriately and merge.

[jbrockmendel]

Yes, I agree that if the user explicitly specifies a non-standard UTC, that should take precedence.

[pganssle]

OK, I've tweaked and rewritten the commit history of this PR to my nitpicky satisfaction, ready for merge when CI passes.

[pganssle]

Thanks @jbrockmendel for the patience. Now to continue working through the backlog on all my projects...