Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

BUG: date parsers use different tz offsets #12064

Closed
chris-b1 opened this issue Jan 16, 2016 · 5 comments

Comments

Projects
None yet
3 participants
@chris-b1
Copy link
Contributor

commented Jan 16, 2016

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

This comment has been minimized.

Copy link
Contributor

commented Jan 16, 2016

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!

@jreback jreback added this to the Next Major Release milestone Jan 16, 2016

@chris-b1

This comment has been minimized.

Copy link
Contributor Author

commented Jan 16, 2016

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

This comment has been minimized.

Copy link
Contributor

commented Jan 16, 2016

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

This comment has been minimized.

Copy link
Contributor Author

commented Jan 18, 2016

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

This comment has been minimized.

Copy link
Contributor

commented Jan 19, 2016

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.