GH-853: Allow ISO String Binding for Date, Time, and Timestamp

[sanskritimbora]

As a developer I want to be able to do query parameter/JDBC Statement binding for Date, Time and Timestamp date types using an iso formatted string. This will help enable the use of 3rd party tools that use ISO string formats for bindings.

Given An Anybase JDBC connection and query that uses parameterization of a Date, Time and/or Timestamp field
When setParameter is called with a valid ISO formatted string
Then Anybase accepts the request and returns appropriate success responses

Sample client use case:

    insertStatement.setString(1, "2025-08-14T15:53:00.000Z");
    insertStatement.setString(2, "2025-04-01");
    insertStatement.setString(3, "21:39:50");

[lidavidm]

Can you create an issue for this, and properly name the PR? ("GH-NNN: Allow binding ISO timestamp strings to date/time types" or something)

[sanskritimbora]

Yes, I have been waiting to receive approval to create a ticket on ASF for Arrow Project. I have sent an email to the dev mail - dev@arrow.apache.org. Once I create the issue I will add more details to the PR.

Is there anything more I can do to expedite this process of receiving access?

[lidavidm]

We use GitHub issues. You should not need approval.

[lidavidm]

(Note that we do NOT use JIRA.)

[kou]

FYI: You can create a new issue from https://github.com/apache/arrow-java/issues/new/choose .

[sanskritimbora]

Fixes #852

[sanskritimbora]

Thank you for the quick responses and the links, I have linked the PR to the issue created.

[lidavidm]

Can you fix the title?

[lidavidm]

Thanks for adding new tests!

[lidavidm]

Isn't this wrong? DateMilliVector is supposed to store millisecond timestamps representing dates (yes, this is a bad representation) so it should be toEpochDay() * 24 * 60 * 60 * 1000.

[sanskritimbora]

That is correct, I made the correction, thanks for pointing out :)

[lidavidm]

Hmm, so we only allow timestamps with the Z suffix - but we can bind to naive timestamp vectors too. And we don't allow timestamps without the suffix. (We could always relax that later, though.)

[sanskritimbora]

Yes, that's correct. Currently, we only accept timestamps with the Z suffix, but we can easily relax this restriction later to support naive timestamps if needed.

[lidavidm]

I think we shouldn't allow binding timestamps with timezones to columns that don't have timezones in principle. Although what happens the Z suffix is probably unambiguous in this case I think if we ever allow other timezones then it becomes a problem.

[lidavidm]

@jbonofre or @aiguofer any opinions on the behavior here?

[lidavidm]

I think that's the last question I have.

[lidavidm]

@jbonofre or @aiguofer any opinions on the behavior here?