concat of tz series and no tz results in attribute error.

[varunkumar-dev]

import pandas as pd
x = pd.Series(pd.date_range('20151124 10:00', '20151124 11:00', freq = '1h', tz = "UTC") )
y = pd.Series(pd.date_range('2012-01-01', '2012-01-03'))
pd.concat([x,y])

AttributeError: 'numpy.ndarray' object has no attribute 'tz_localize'

Is it a bug or not supported ?

[jreback]

this is realted to #11705

this should work, but both series get converted to object dtype first

so this is a bug in there somewhere

[varunkumar-dev]

@jreback If we convert to object , we loose the timezone information. Is it the best way to handle this ?

[jreback]

tz that compat iow they match should be preserved
if no tz then they are returned as naive
if things are mixed then they get converts to object

this already exists - this is just missing a conversion somewhere I think - if u add tests as I suggest it should be easy to figure out

[varunkumar-dev]

@jreback
I tried converting datetimenz and datetime to objects. But it does not help.
For the above mentioned example, np.concatenate() returns a datetime array

[datetime.datetime(2015, 11, 24, 10, 0)
 datetime.datetime(2015, 11, 24, 11, 0) 
datetime.datetime(2012, 1, 1, 0, 0)
 datetime.datetime(2012, 1, 2, 0, 0)]

Creating a series will always return datetime series not object.

Output

0   2015-11-24 10:00:00
1   2015-11-24 11:00:00
0   2012-01-01 00:00:00
1   2012-01-02 00:00:00
dtype: datetime64[ns]

Any suggestions?

[jreback]

just step thru the code
FYI - we rarely use native numpy routines when non numeric types - they don't have things well

[varunkumar-dev]

@jreback In this group by test case we expect a datetime64[ns] series . "combining multiple / different timezones yields UTC". And in the above example we expect an object . Is it not an inconsistency ? Should it be datetime64[ns] ?

[jreback]

see if you can find when that groupby behavior was put in place. IIRC this was though to be more natural.

cc @sinhrks

but as I look now, we have a policy of only combing the exact same timezones, and converting to object dtype otherwise. There is an exception though because whenever you convert to an actual numpy array, and you have all uniform dtypes then you will get converted to UTC then to naive.

So the answer to your question, is that we may need to change this groupby test case to conform. (and possibly note as an API change to clean this up).

[sinhrks]

This is related to #11455 also.

IIRC, I had test failues in the same groupby tests when I tried to fix #11455. And it is also related to current DatetimeIndex creation process. I'll revisit this to find more detail.

[jreback]

was closed by #12195