Skip to content

BUG: astype('datetime64[us]') has no effect on datetime64[ns] series #49203

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

Closed
3 tasks done
gtopper opened this issue Oct 20, 2022 · 1 comment
Closed
3 tasks done

BUG: astype('datetime64[us]') has no effect on datetime64[ns] series #49203

gtopper opened this issue Oct 20, 2022 · 1 comment
Labels
Astype Bug Needs Triage Issue that has not been reviewed by a pandas team member Non-Nano datetime64/timedelta64 with non-nanosecond resolution

Comments

@gtopper
Copy link

gtopper commented Oct 20, 2022

Pandas version checks

  • I have checked that this issue has not already been reported.

  • I have confirmed this bug exists on the latest version of pandas.

  • I have confirmed this bug exists on the main branch of pandas.

Reproducible Example

import pandas as pd

data = [
    {
        'time': pd.Timestamp('2020-01-26 12:41:37.123456789')
    },
]
df = pd.DataFrame(data, columns=['time'])

df['time'] = df['time'].astype('datetime64[us]')

print(df['time'][0])

df.to_parquet("out.pq", index=True)

Issue Description

In 1.5.0 and 1.5.1, it prints

2020-01-26 12:41:37.123456789

and raises an error:

Traceback (most recent call last):
  File "/Users/gal/work/storey/pandas-1.5.1-issue.py", line 14, in <module>
    df.to_parquet("out.pq", index=True)
  File "/Users/gal/.local/share/virtualenvs/storey-ptFrrr4H/lib/python3.8/site-packages/pandas/util/_decorators.py", line 211, in wrapper
    return func(*args, **kwargs)
  File "/Users/gal/.local/share/virtualenvs/storey-ptFrrr4H/lib/python3.8/site-packages/pandas/core/frame.py", line 2974, in to_parquet
    return to_parquet(
  File "/Users/gal/.local/share/virtualenvs/storey-ptFrrr4H/lib/python3.8/site-packages/pandas/io/parquet.py", line 430, in to_parquet
    impl.write(
  File "/Users/gal/.local/share/virtualenvs/storey-ptFrrr4H/lib/python3.8/site-packages/pandas/io/parquet.py", line 204, in write
    self.api.parquet.write_table(
  File "/Users/gal/.local/share/virtualenvs/storey-ptFrrr4H/lib/python3.8/site-packages/pyarrow/parquet.py", line 2034, in write_table
    writer.write_table(table, row_group_size=row_group_size)
  File "/Users/gal/.local/share/virtualenvs/storey-ptFrrr4H/lib/python3.8/site-packages/pyarrow/parquet.py", line 701, in write_table
    self.writer.write_table(table, row_group_size=row_group_size)
  File "pyarrow/_parquet.pyx", line 1451, in pyarrow._parquet.ParquetWriter.write_table
  File "pyarrow/error.pxi", line 99, in pyarrow.lib.check_status
pyarrow.lib.ArrowInvalid: Casting from timestamp[ns] to timestamp[us] would lose data: 1580042497123456789

Expected Behavior

Up until pandas 1.4.4, it would print

2020-01-26 12:41:37.123456

and create the parquet file.

Installed Versions

INSTALLED VERSIONS

commit : 91111fd
python : 3.8.9.final.0
python-bits : 64
OS : Darwin
OS-release : 21.6.0
Version : Darwin Kernel Version 21.6.0: Mon Aug 22 20:17:10 PDT 2022; root:xnu-8020.140.49~2/RELEASE_X86_64
machine : x86_64
processor : i386
byteorder : little
LC_ALL : None
LANG : None
LOCALE : None.UTF-8

pandas : 1.5.1
numpy : 1.22.4
pytz : 2022.5
dateutil : 2.8.2
setuptools : 65.5.0
pip : 22.2.2
Cython : None
pytest : 5.4.3
hypothesis : None
sphinx : 3.5.4
blosc : None
feather : None
xlsxwriter : None
lxml.etree : None
html5lib : None
pymysql : None
psycopg2 : None
jinja2 : 3.0.3
IPython : 7.31.0
pandas_datareader: None
bs4 : 4.10.0
bottleneck : None
brotli : None
fastparquet : None
fsspec : 2022.10.0
gcsfs : None
matplotlib : None
numba : None
numexpr : None
odfpy : None
openpyxl : None
pandas_gbq : None
pyarrow : 6.0.1
pyreadstat : None
pyxlsb : None
s3fs : 0.6.0
scipy : None
snappy : None
sqlalchemy : 1.4.29
tables : None
tabulate : 0.8.9
xarray : None
xlrd : None
xlwt : None
zstandard : None
tzdata : None

@gtopper gtopper added Bug Needs Triage Issue that has not been reviewed by a pandas team member labels Oct 20, 2022
gtopper pushed a commit to gtopper/storey that referenced this issue Oct 20, 2022
Due to pandas-dev/pandas#49203

Previously we restricted it due to this other issue: pandas-dev/pandas#48767
gtopper pushed a commit to mlrun/storey that referenced this issue Oct 23, 2022
Due to pandas-dev/pandas#49203

Previously we restricted it due to this other issue: pandas-dev/pandas#48767
@jbrockmendel
Copy link
Member

This works now that we have non-nano support. Closing as complete.

@jbrockmendel jbrockmendel added the Non-Nano datetime64/timedelta64 with non-nanosecond resolution label Mar 4, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Astype Bug Needs Triage Issue that has not been reviewed by a pandas team member Non-Nano datetime64/timedelta64 with non-nanosecond resolution
Projects
None yet
Development

No branches or pull requests

2 participants