[C++][Python] Compute function to generate date from year / month / day

[aandrestrumid]

Describe the enhancement requested

There are currently pyarrow functions converting a pa.date32() to its year / month / day. But there isn't a function that does the invert, accepting a year, a month and a day and returning a pa.date32.

The current work around involve either using python datetime.date (but it is slow and the range is limited). Alternatively one can build a date string from the component and parse it. But it's far from ideal

import pyarrow as pa
import pyarrow.compute as pc

table = pa.table({"year": [2024, 2025], "month": [3, 7], "day": [10, 4]})

date_str = pc.binary_join_element_wise(
    pc.cast(table["year"],  pa.string()),
    pc.utf8_lpad(pc.cast(table["month"], pa.string()), 2, "0"),
    pc.utf8_lpad(pc.cast(table["day"],   pa.string()), 2, "0"),
    "-"
)

dates = pc.cast(date_str, pa.date32())

Component(s)

Python

[rok]

Thanks for reporting @aandrestrumid ! Is this something you'd like to contribute?
As for the approach - I imagine we would want to create a c++ kernel that would accept temporal components of a date/timestamp. Kernel would then be available through compute interface - pc.compose_timestamp(...) perhaps?.

[Reranko05]

Hi @rok, I'd be interested in working on this if it's still available.

Before I start, is the preferred direction still a dedicated date composition kernel (e.g. make_date(year, month, day)), or would you prefer a more general temporal composition API as mentioned above (compose_timestamp(...)) with date support built on top of that?

[rok]

Hey @Reranko05 ! I believe this is currently open to work on and we best discuss design here before any work begins.
I don't think it would be beneficial to do a roundtrip through string because that would be detrimental to performance and accuracy (See open strptime issues).
One design option would be that I see is that input would be a struct array with prescribed integer fields. There could be better designs @pitrou

[Reranko05]

Thanks for the clarification @rok. The struct-based approach sounds good. I'll follow the design discussion here and see where the consensus lands before exploring an implementation.