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
BUG: dtype ignored in pd.read_excel #39898
Comments
You can read a little about this here: https://pandas.pydata.org/pandas-docs/stable/user_guide/text.html#text-types If you feel this addresses the issue please close or revert back. |
As @attack68 mentioned, we do not support str, we support object dtype or the StringDtype in DataFrames |
this is actually a bit trickier converters are applied first to the raw fields then dates are parsed by default ; since these are strings already so this is as designed and documented - |
Thanks a lot for your replies, I was not aware of this update and the use of StringDtype. The correct dtype seems to be applied now:
However it's strange not to have consistent results between read_excel and read_csv.
How can I get the same output using read_excel ? (date and time showing as they are in the original excel file) |
I don't think you can, due to the way date and time are stored in XLSX. The excel reader engines in read_excel give you the correct time and date values, but they do not need to parse date strings for that (in the most common case). You can unzip your test file and look into the sheet XML to see how the values are stored. |
Since this behavior is as designed, appears that there's nothing to address in pandas so closing as a usage question |
I'm trying to read an excel file with pd.read_excel().
The excel file has 2 columns Date and Time and I want to read both columns as str not the excel dtype.
Example of the excel file
test1.xlsx
When using the dtype or the converters arguments the dtype of the columns remain the same
Same thing when using converters
I have also tried to use other engine but the result is always the same.
pd.show_versions()
This seems too obvious to be an unreported bug and I apologise if the problem comes from my side.
The text was updated successfully, but these errors were encountered: