-
-
Notifications
You must be signed in to change notification settings - Fork 18.6k
Version 0.15 MultiIndex forces Datetime.date objects to Timestamp objects #8802
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
Comments
see #7888 and associated PR. Their was an inconsistency in how date-likes (datetime.date,datetime.datetime,Timestamp) were inferred in a MultiIndex level. This led to the creation of an object dtyped Index rather than a DatetimeIndex. datetime.date are second class objects in pandas as they are not efficiently represented. Is their a reason you are not using Timestamp/datetime.datetime ? If you really really want to create this, you can do this:
|
Thanks for the reply. I looked for previous related issues but didn’t find them. Sorry if I’ve wasted your time. From: jreback [mailto:[email protected]] see #7888#7888 and associated PR. Their was an inconsistency in how date-likes (datetime.date,datetime.datetime,Timestamp) were inferred in a MultiIndex level. This led to the creation of an object dtyped Index rather than a DatetimeIndex. datetime.date are second class objects in pandas as they are not efficiently represented. Is their a reason you are not using Timestamp/datetime.datetime ? If you really really want to create this, you can do this: In [8]: pd.MultiIndex.from_arrays([Index([datetime.date(2013,1,1)]),['a']]) Out[8]: MultiIndex(levels=[[2013-01-01], [u'a']],
— IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses. |
their is no need to keep separate date/time components and it makes is quite inefficient to do so. You can get at the date or time components in a number of ways, e.g. if you are resampling, or you can just index on the times. A more complete example would help me understand what you are trying to do. |
One example would be using unstack on the time component to convert a column into a data frame with columns corresponding to the times and index given by the remaining levels. Is it possible to do this directly with a DateTimeIndex? Also, consider this example using a DateTimeIndex on the second level of a MultiIndex with integers on the first. I'm tryin to locate rows corresponding to a list of index tuples. In [67]: pairs = [(34142, '20090422'), (34142, '20090423')] dt_pairs = [(34142, datetime.date(2009, 4, 22)), (34142, datetime.date(2009, 4, 23))] In [91]: df.loc[pairs] In [93]: df.loc[dt_pairs] In [90]: df.loc[pairs[0]] In [94]: df.loc[dt_pairs[0]] However, It works perfectly fine with datetime.date objects in the index: In [92]: df2.loc[dt_pairs] I think I will stick to 0.14 for the current project which already has 2000+ lines of code depending on the use of datetime.date objects and try to incorporate Timestamps into future projects. |
I recently updated Pandas and found this strange behaviour which broke some of my existing code.
I was using a column of Datetime.date objects as a the second level in a two-level MulitIndex.
However, when setting the index with the latest version, the Datetime.date objects are converted to Timestamp objects with 00:00:00 as the time component:
This doesn't happen with version 0.14 or older.
There is a hack to get around it, setting the dates to a single level index, adding the other level and then swapping:
This seems strange and I wondered was it intentional.
The text was updated successfully, but these errors were encountered: