BUG: Unexpected %S strftime behaviour when using PyArrow timestamps

[Giuzzilla]

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
series = pd.Series(pd.to_datetime(["2023-04-05T00:00:00"]), dtype="timestamp[ns][pyarrow]")
series.dt.strftime("%Y-%m-%dT%H:%M:%S")

OUTPUT:
2023-04-05T00:00:00.000000000

Issue Description

I've started using Pandas (2.1.0) with the PyArrow backend (e.g. for read_sql) and it's currently breaking my code by returning seconds together with their fractional part when using .dt.strftime("%Y-%m-%dT%H:%M:%S").

Apparently, this is the expected behavior by looking at the PyArrow strftime documentation, but at the same time pandas documentation refers to the Python string format docs in their strftime documentation (which allow for a separate format code for the fractional part, %f).

This can be mitigated by casting the timestamps to timestamp[s][pyarrow] (second precision). However, timestamps/datetime get automatically casted to timestamp[ns][pyarrow] (nanosecond precision) when, for example, reading from a SQL database and that's quite convenient.

I thought this could be considered to be a bug in Pandas (especially considering that Pandas wants to increase their reliance on PyArrow by making it a mandatory requirement in 3.x) or at least the documentation would benefit from a clarification.

Expected Behavior

I'd expect pandas' strftime to keep returning strings exclusively reporting non-fractional seconds when using the %S format code, just as when using standard numpy dtypes:

import pandas as pd
series = pd.Series(pd.to_datetime(["2023-04-05T00:00:00"]))
series.dt.strftime("%Y-%m-%dT%H:%M:%S")

OUTPUT: 2023-04-05T00:00:00

Installed Versions

INSTALLED VERSIONS

commit : ba1cccd
python : 3.11.5.final.0
python-bits : 64
OS : Linux
OS-release : 5.14.0-1054-oem
Version : #61-Ubuntu SMP Fri Oct 14 13:05:50 UTC 2022
machine : x86_64
processor : x86_64
byteorder : little
LC_ALL : None
LANG : en_US.UTF-8
LOCALE : en_US.UTF-8

pandas : 2.1.0
numpy : 1.24.1
pytz : 2022.7
dateutil : 2.8.2
setuptools : 68.1.2
pip : 23.1.2
Cython : None
pytest : None
hypothesis : None
sphinx : None
blosc : None
feather : None
xlsxwriter : None
lxml.etree : None
html5lib : 1.1
pymysql : None
psycopg2 : 2.9.5
jinja2 : 3.1.2
IPython : 8.11.0
pandas_datareader : None
bs4 : 4.9.3
bottleneck : 1.3.7
dataframe-api-compat: None
fastparquet : None
fsspec : 2022.11.0
gcsfs : None
matplotlib : 3.7.1
numba : 0.57.1
numexpr : 2.8.5
odfpy : None
openpyxl : 3.0.9
pandas_gbq : None
pyarrow : 13.0.0
pyreadstat : None
pyxlsb : None
s3fs : 2022.11.0
scipy : 1.11.2
sqlalchemy : 1.4.49
tables : None
tabulate : None
xarray : None
xlrd : 1.2.0
zstandard : None
tzdata : 2023.3
qtpy : None
pyqt5 : None

[abidkhan484]

take

[abidkhan484]

Hi folks,

Since I am new to open source and not familiar with pandas source code, it's taking a bit more time to figure out the root cause of the bug. I am still on it.

Any suggestion is highly appreciated.

[abidkhan484]

I found a clue to fix the issue given below. Actually, It's a behavior of pyarrow.compute.strftime and pandas is just using the implementation.

>>> import datetime
>>> import pyarrow as pa
>>> import pyarrow.compute as pc
>>> 
>>> array = pa.array([datetime.datetime(2023, 9, 11, 9)], type=pa.timestamp('ns'))
>>> chunked_array = pa.chunked_array([array])
>>> formatted_time = pc.strftime(chunked_array, format="%Y-%m-%dT%H:%M:%S")
>>> print(formatted_time)
[
  [
    "2023-09-11T09:00:00.000000000"
  ]
]

Solution:

1. It may be possible to update the wrapper of pandas implementation.
2. If pyarrow.compute.strftime is fixed, then it will be solved automatically.

pyarrow version '7.0.0'
pandas version '2.2.0dev0+176.gf03482094a.dirty'

[Giuzzilla]

@abidkhan484
Right, I mentioned the Pyarrow function in the Issue Description. It's well documented on their documentation so I don't think we should expect them fixing it.

I'm not sure what's the best solution, but my humble guess is that we should update the Pandas wrapper somehow.

[abidkhan484]

take

[abidkhan484]

As per my finding, this is the wrapper method that is responsible for strftime implementation for pyarrow.