Partial date string indexing doesn't work on MultiIndex

[rben01]

Code Sample, a copy-pastable example if possible

date_idx = pd.date_range('2019', periods=5, freq='MS')
df_single = pd.DataFrame(list(range(5)), index=date_idx)
df_multi = pd.DataFrame(list(range(15)), 
                        index=pd.MultiIndex.from_product([date_idx, list(range(3))], 
                                                         names=['x', 'y']))

# All of the following get rows starting in February
df_single['2019-2':]
df_single.loc['2019-2':]
df_single.loc(axis=0)['2019-2':]

# But none of the following do -- not even the last one
df_multi['2019-2':]  # TypeError: '<' not supported between instances of 'int' and 'slice'
df_multi.loc['2019-2':]  # Same error
df_multi.loc(axis=0)['2019-2':]  # Same error
df_multi.loc(axis=0)['2019-2':, :]  # AttributeError: 'int' object has no attribute 'stop'

Problem description

For single (not multi-) datetime indexes, you can use a string coercible to a pd.Timestamp to slice the dataframe. For MultiIndexes with one level a DatetimeIndex, this indexing is not possible, no matter how precisely you specify the slice axes and levels (and even when the dataframe is sorted by the DatetimeIndex level, and the DatetimeIndex level is the outermost level).

Expected Output

df_multi.loc(axis=0)['2019-2':, :] should certainly slice the rows correctly, as

1. The slicing is totally unambiguous (nothing needs to be inferred by pandas -- the axis and all slice levels are provided)
2. The dataframe is sorted by the DatetimeIndex level
3. The DatetimeIndex level is outermost

Cases more complicated than this might have some caveats, but the example provided above should definitely work.

Output of pd.show_versions()

INSTALLED VERSIONS

commit: None
python: 3.7.1.final.0
python-bits: 64
OS: Windows
OS-release: 2012ServerR2
machine: AMD64
processor: Intel64 Family 6 Model 45 Stepping 2, GenuineIntel
byteorder: little
LC_ALL: None
LANG: None
LOCALE: None.None

pandas: 0.23.4
pytest: 4.0.2
pip: 18.1
setuptools: 40.6.3
Cython: 0.29.2
numpy: 1.15.4
scipy: 1.1.0
pyarrow: None
xarray: None
IPython: 7.2.0
sphinx: 1.8.2
patsy: 0.5.1
dateutil: 2.7.5
pytz: 2018.7
blosc: None
bottleneck: 1.2.1
tables: 3.4.4
numexpr: 2.6.8
feather: None
matplotlib: 3.0.2
openpyxl: 2.5.12
xlrd: 1.2.0
xlwt: 1.3.0
xlsxwriter: 1.1.2
lxml: 4.2.5
bs4: 4.6.3
html5lib: 1.0.1
sqlalchemy: 1.2.15
pymysql: None
psycopg2: None
jinja2: 2.10
s3fs: None
fastparquet: None
pandas_gbq: None
pandas_datareader: None

[gfyoung]

cc @toobaz

Cases more complicated than this might have some caveats, but the example provided above should definitely work.

Interesting proposal, but statements like the one above worry me, since if we were to implement this, we would have to address those caveats and very clearly delineate which cases are (or are not) supported.

[jreback]

this is implemented for multiindexing a while back so this looks like a bug

[toobaz]

I agree this should work. The best fix might be a rewrite, but adding

                    if isinstance(start, slice):
                        start = start.start

after

pandas/pandas/core/indexes/multi.py

Line 2616 in 683c7b5

start = level_index.get_loc(key.start)

seems to solve this specific issue.