Fix unrecognized 'Z' UTC designator

[broessli]

closes #8771

[jreback]

ok, looks simple enough! cross-fingers other tests pass!
pls add a release note as well (referencing the original issue) (put in bug-fixes, though you can say regression)

[jreback]

maybe change the comment to explain the 0/1 return

[broessli]

Hi, do you need me to do other modifications before merging? Let me know

[jreback]

looks good. pls rebase and squash. ping when green.

[broessli]

done!

[jreback]

merged via c03e92f

[jreback]

@broessli hmm, I think this was changed before the latest travis build. Thought it was green.

Can you see what the problem is and and do a follow up PR? thanks (pls submit a new PR, can't push to this one anymore)

https://travis-ci.org/pydata/pandas/builds/41039139

[broessli]

Yes, sorry about that. The issue seems related to dateutil behavior, which is the fallback when parsing dates with ...Z00, depending on the version we can get a time zone equal to tzutc() or tzlocal(). Not sure how to handle this (besides dropping the test on Z00...)

[broessli]

By the way, checking ISO 8601 I am not sure what to expect exactly with Z00, is it really legit?

[jreback]

so it give one answer on dateutil 1.5 and a different on 2.1/2.2?

you can do the test like this:

from distutils.version import LooseVersion

.....


if LooseVersion(dateutil.__version__) >= '2.2':
    #.....
else:
    # ....

I am not sure of the defined behavior of ...Z00

cc @rockg ?

[broessli]

Actually, testing on my machine, I always get tzutc() regardless of dateutil's version, cannot figure out why this is different on Travis

[jreback]

hmm, I think this might have to do with the cache not updating because only the .c files were changed (and not the cython files). let me see.

[jreback]

reverted for now: 6f48d4a

got ahead and rebase on master and put up a new PR (close this one)

[jreback]

cc @dbew

any thoughts on the above?

https://travis-ci.org/pydata/pandas/builds/41039139

[dbew]

Nothing jumps out, I'm afraid.

There were definitely differences between python 3 and python 2 when I did the original dateutil work but the issues I had were all around UTC and the implementation of the timezones, not tzlocal and parsing.

Looking at the parse code in dateutil, I think it reads the timezone name and first tests if it matches the local timezone (tzname in time.tzname) then tests if it matches UTC - so if 'Z' matches the local timezone then it wouldn't be reported at UTC.