Thanks for opening a pull request!

If this is not a minor PR. Could you open an issue for this pull request on GitHub? https://github.com/apache/arrow/issues/new/choose

Opening GitHub issues ahead of time contributes to the Openness of the Apache Arrow project.

Then could you also rename the pull request title in the following format?

GH-${GITHUB_ISSUE_ID}: [${COMPONENT}] ${SUMMARY}

or

MINOR: [${COMPONENT}] ${SUMMARY}

In the case of PARQUET issues on JIRA the title also supports:

PARQUET-${JIRA_ISSUE_ID}: [${COMPONENT}] ${SUMMARY}

See also:

• Other pull requests
• Contribution Guidelines - Contributing Overview

⚠️ GitHub issue #40893 has been automatically assigned in GitHub to PR creator.

If there is an idea for a better "stringification" of this type, I'm happy to implement it. The postgres interval type comes to mind, though that would be inconsistent with the existing Oracle type stringifications.

If there is an idea for a better "stringification" of this type, I'm happy to implement it. The postgres interval type comes to mind, though that would be inconsistent with the existing Oracle type stringifications.

Isn't ISO-8601/RFC3339 a good and relatively well-known format?

Isn't ISO-8601/RFC3339 a good and relatively well-known format?

I think that should work. The toString() of Period and Duration produce ISO-8601 compatible strings already. I thought they had overlapping units but upon second glance it doesn't appear they do, so I can more or less concatenate them and get a string.

I was going to ask what other drivers do, but it appears Postgres also has a custom type (PGInterval). So this is probably reasonable, except I wonder, since we shade the JAR for distribution, this will force people to refer to a shaded class?

I suppose Joda Time's period was not fully adopted into Java, as its Period does have time units... https://www.joda.org/joda-time/apidocs/org/joda/time/Period.html

I suppose Joda Time's period was not fully adopted into Java, as its Period does have time units... https://www.joda.org/joda-time/apidocs/org/joda/time/Period.html

I guess the driver could implement java.time.TemporalAmount which would be as standard as possible?

So what I'm going for:

• PeriodDuration is still the object returned by getObject() to JDBC clients (matching the return type on the underlying vector)
• PeriodDuration should implement TemporalAmount
• The string returned by its StringGetter should be an ISO-8601 interval

Does that sound right @laurentgo @lidavidm ?

It's perhaps worth pointing out that I'll basically be re-implementing ThreeTen's PeriodDuration class. I assume it's not desirable to replace Arrow's PeriodDuration with that class entirely.

That sounds good to me, thank you.

We probably don't want to take a dependency on that, no. I suppose we have to just live with the shaded name, too (probably for the best if there's no stdlib type that fits).

Hmm, it appears ISO8601 durations as proposed for ECMAScript do not allow negative components. But Java does this (as we see here), other systems like Pandas do as well, and at some point the ISO spec was revised to allow it (even though this doesn't seem to have been made easily accessible...): https://www.postgresql.org/message-id/9q0ftb37dv7.fsf%40gmx.us

so I'm ok with it.

After merging your PR, Conbench analyzed the 6 benchmarking runs that have been run so far on merge-commit 17a5368.

There was 1 benchmark result indicating a performance regression:

• Commit Run on arm64-m6g-linux-compute at 2024-03-31 18:26:09Z
  • dataset-read (Python) with async=True, dataset=nyctaxi_multi_parquet_s3, pre_buffer=true

The full Conbench report has more details. It also includes information about 3 possible false positives for unstable benchmarks that are known to sometimes produce them.