[Python][Compute] Make pyarrow.compute.strptime %Y handling consistent with time.strptime

[no23reason]

Describe the enhancement requested

The pyarrow.compute.strptime handles the %Y format part (i.e. 4-digit year) differently from the built-in time.strptime:
When the year part of the input has only two digits, time.strptime fails to parse it, while pyarrow.compute.strptime parses it with no error yielding a result with a year in the 1st century.

For example

>>> import pyarrow as pa
>>> import pyarrow.compute as pc
>>> import time
>>> input = "01-01-23"
>>> format = "%m-%d-%Y"
>>> time.strptime(input, format)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/no23reason/.pyenv/versions/3.11.4/lib/python3.11/_strptime.py", line 562, in _strptime_time
    tt = _strptime(data_string, format)[0]
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/no23reason/.pyenv/versions/3.11.4/lib/python3.11/_strptime.py", line 349, in _strptime
    raise ValueError("time data %r does not match format %r" %
ValueError: time data '01-01-23' does not match format '%m-%d-%Y'
>>> pc.strptime(pa.array([input]), format=format, unit="s")
<pyarrow.lib.TimestampArray object at 0x152e40c40>
[
  0023-01-01 00:00:00
]

I believe the pyarrow.compute.strptime should also fail in this case as it most likely means that the format is wrong.

Component(s)

Python

[rok]

Thanks for reporting this @no23reason! Pyarrow uses system's strptime and hence doesn't really follow Python's strptime conventions.
This falls under #31324 umbrella.

[no23reason]

Thank you @rok or the clarification and the umbrella link. I played some more with the C version of strptime (https://onlinegdb.com/Et55gUIpp) and indeed, it parses the years with less than 4 digits 🤯

[rok]

Unfortunately dialects can't be reconciled. We could add a dialect parameter to control behavior but I suspect it would be a significant amount of work and we're not seeing strong demand for it.

[no23reason]

Makes sense. Maybe it would be enough to mention it in the docs of the pyarrow compute, that the function follows C++ semantics, not Python ones 🤔

[rok]

@no23reason that would be good! Want to open a PR?

[no23reason]

Sure, I'll try to get to it later today :)

[no23reason]

Sorry for radio silence, I was able to extend the documentation locally, but was struggling with the python build so that I could preview the changes in the built docs. Will give it some more time when I'm able.

[rok]

No worries!
For simple changes you can also sidestep building docs locally by just opening a PR and use github actions to build a preview - see here.

[no23reason]

Hm, seems that as a first time contributor, I cannot run the preview: #38665 can you please take a look? :)

[rok]

It seems so! I started the CI and the docs build.

[no23reason]

Hm, it seems something is wrong with the CI :( I tried running the archery docker run -v "${PWD}/docs:/build/docs" ubuntu-docs locally, but it also failed with errors like

CMake Error at cmake_modules/FindAzure.cmake:32 (find_package):
  Could not find a package configuration file provided by "azure-core-cpp"
  with any of the following names:

    azure-core-cppConfig.cmake
    azure-core-cpp-config.cmake

let's hope the CI comes around :)