BUG: date parsers use different tz offsets

[chris-b1]

xref #12060

@jreback - my thought was to just convert the dateutil timezone offset (tzoffset) to a pytz offset?

# dateutil
In [1]: pd.Timestamp('2013/01/01 00:00:00+09:00')
Out[1]: Timestamp('2013-01-01 00:00:00+0900', tz='tzoffset(None, 32400)')

# C parser
In [2]: pd.Timestamp('2013-01-01 00:00:00+09:00')
Out[2]: Timestamp('2013-01-01 00:00:00+0900', tz='pytz.FixedOffset(540)')

In [3]: pd.date_range('2013-01-01 00:00:00+09:00', '2014/01/01 00:00:00+09:00')

TypeError                                 Traceback (most recent call last)
<ipython-input-3-d34c322923bc> in <module>()
----> 1 pd.date_range('2013-01-01 00:00:00+09:00', '2014/01/01 00:00:00+09:00')

...

TypeError: Start and end cannot both be tz-aware with different timezones

[jreback]

you might want to make a slightly different error message. But its still a TypeError (even if they mean exactly the same tz). We don't have anywhere where we allow mixing of timezones like this. (and I dont' think we should).

timezone are hard enough!

[chris-b1]

just to be clear, I didn't think that date_range should work as is - question is on the parsing - if it falls back to dateutil should it really be a different tz offset?

This popped up in the tests in #12060 - if the iso8601 parser is more flexible, it's somewhat easy to have two similar looking dates, but only 1 hits the C parser. There it was:

date_range('2013/1/1 0:00:00+9:00', '2016/1/1 23:59:59+09:00')

[jreback]

oh I c. so we fallback to dateutil to parse and thus it generates a dateutil tz offset.
is no leading 0 on the offset not ISO8601? (e.g. +9:00), while (+09:00) ISO?

[chris-b1]

Yeah, that's the issue. Though looking at again, I suppose I could also have the ISO parser handle times without leading 0s, I think it's unambiguous as long as the : separators are present.

[jreback]

we can deal with issue separatly (e.g. parsing leading/lacking 0's for the tz's)