-
-
Notifications
You must be signed in to change notification settings - Fork 18.5k
Where method does not properly handle values with datetimes with TZ #21546
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
xrefing my #21469 (comment) and probably the root cause for #21469 |
@mroeschke Do you have an idea why there's the weirdly shaped result from DataFrame.where with a tz column? I think you're more familiar with the internals here than I am. |
@mroeschke I think I figured out at least the weirdly-shaped result issue here (not sure about the 1-D case). As indicated at your comment on #21469 the issue is in |
Thanks for investigating @Liam3851. IIRC DatetimeTZBlocks only contain data ( |
@mroeschke Been digging into this a bit further. Do you know, what is the contract regarding the dimension of In particular, ''' need to to_dense myself (and always return a ndim sized object) ''' DatetimeTZBlock overrides Similarly in
which ensures that values is self.ndim (2) dimensions. However, if
Thoughts? |
@jreback architected the From what I understand at a high level for DataFrames, it's composed from a group of Blocks that groups the values of the DataFrame by dtype along the columns. In most cases these Blocks can store 2D values, so overall the collection (concatination) of 2D values from the Blocks comprise the overall 2D dimension of the DataFrame. The reason why Beyond that, I am not familiar with how the internals makes sure the dimensions line up or routines that would coerce |
@mroeschke expl is correct. yeah its currently a bummer that we aren't super consistent internally how we handle naive datetimes (2D) vs tz-aware (1D), but that's the direction we have been moving. So various compat things exist to handle this. We basically have too many accessors that do slightly different things, but the cleanup is non-trivial / hard. For this issue, prob just need to see where its getting coerced to 2D (or vice-versa) and maybe override the method in here's a patch which works on the above example. doesn't seem to break any series tests, but have a go. (breaks something in dataframe tests :<)
|
Code Sample, a copy-pastable example if possible
Series input:
Series output:
DataFrame input:
DataFrame output:
Problem description
where
fails on both Series and DataFrame when given values that have datetime-tz dtype. Both work fine with naive datetime values. Series ends up with a mix of datetime-tz and what appear to be i8 values; datetime-tz columns in DataFrames end up with the wrong shape (perhaps a concat along the wrong axis is occurring?).Expected Output
Series:
DataFrame:
Output of
pd.show_versions()
INSTALLED VERSIONS
commit: 2f4d393
python: 3.6.5.final.0
python-bits: 64
OS: Windows
OS-release: 7
machine: AMD64
processor: Intel64 Family 6 Model 62 Stepping 4, GenuineIntel
byteorder: little
LC_ALL: None
LANG: None
LOCALE: None.None
pandas: 0.24.0.dev0+113.g263386389
pytest: 3.6.0
pip: 10.0.1
setuptools: 39.2.0
Cython: 0.28.3
numpy: 1.14.2
scipy: 1.0.0
pyarrow: 0.8.0
xarray: 0.10.6
IPython: 6.4.0
sphinx: 1.7.5
patsy: 0.5.0
dateutil: 2.7.3
pytz: 2018.4
blosc: None
bottleneck: 1.2.1
tables: 3.4.3
numexpr: 2.6.4
feather: 0.4.0
matplotlib: 2.2.2
openpyxl: 2.5.3
xlrd: 1.1.0
xlwt: 1.3.0
xlsxwriter: 1.0.5
lxml: 4.1.1
bs4: 4.6.0
html5lib: 1.0.1
sqlalchemy: 1.2.8
pymysql: 0.8.1
psycopg2: None
jinja2: 2.10
s3fs: 0.1.5
fastparquet: 0.1.5
pandas_gbq: None
pandas_datareader: None
The text was updated successfully, but these errors were encountered: