Skip to content

GH-37118 [Java][arrow-jdbc] Support converting JDBC TIMESTAMP_WITH_TIMEZONE to Arrow #37088

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
wants to merge 2 commits into
base: main
Choose a base branch
from
Draft

GH-37118 [Java][arrow-jdbc] Support converting JDBC TIMESTAMP_WITH_TIMEZONE to Arrow #37088

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
71cbfd7
Correctly consume JDBC timestamps when converting to Arrow
aiguofer Aug 9, 2023
6a97ab8
Small fix
aiguofer Aug 9, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
11 changes: 4 additions & 7 deletions java/adapter/jdbc/src/main/java/org/apache/arrow/adapter/jdbc/JdbcToArrowUtils.java
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -188,12 +188,9 @@ public static ArrowType getArrowTypeFromJdbcType(final JdbcFieldInfo fieldInfo,
case Types.TIME:
return new ArrowType.Time(TimeUnit.MILLISECOND, 32);
case Types.TIMESTAMP:
final String timezone;
if (calendar != null) {
timezone = calendar.getTimeZone().getID();
} else {
timezone = null;
}
return new ArrowType.Timestamp(TimeUnit.MILLISECOND, null);
case Types.TIMESTAMP_WITH_TIMEZONE:
final String timezone = calendar == null ? null : calendar.getTimeZone().getID();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, there is still an underlying timezone, right? I guess we just don't know without writing database-specific code. It might be better to error in this case?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah this one is tough. As I understand it, TIMESTAMP_WITH_TIMEZONE means that each record includes its own timezone as a UTC offset (or at least, that seems to be the case with Snowflake). Based on the JDBC spec, ResultSet.getTimestamp(int columnIndex, Calendar cal) does the following This method uses the given calendar to construct an appropriate millisecond value for the timestamp if the underlying database does not store timezone information.. This leads me to believe that it parses out the offset from the underlying db and uses that to convert to UTC. If no offset is available, it assumes the timestamp is in w/e is passed in the calendar and then converts it to UTC. Here's an interesting SO on the topic: https://stackoverflow.com/a/63078938/1815486

From my understanding, ArrowType.Timestamp does not support per record timezones and it does not do any conversions on its own. It seems like the timezone is associated with the Vector itself and all records are expected to be in that same timezone. This means we must convert TIMESTAMP_WITH_TIMEZONE values into one specific TZ before we add them to the vector. It's also not exactly clear what it means when the TZ is null (I'm assuming this means it's just a "wall clock" time).

This all leaves some questions:

  • What is the TZ associated with calendar supposed to represent for these functions?
    • The TZ to assume the underlying values are in
    • The TZ to report on the ArrowType
    • The TZ that we should convert values to

There's some important connotations because it depends on whether one is using the arrow-jdbc library to convert values server side, where it's generally safe to use/assume UTC for a lot of things, or client side, where they might want to express values in the user's timezone.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In Arrow, the underlying representation for a timestamp with timezone is always UTC. So if the driver is giving us UTC and converting it, we should always bypass their conversion and construct a timestamp[ms, UTC].

And yes, if there's no timezone, then it's a wall-clock time.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, so Snowflake:

TIMESTAMP_LTZ internally stores UTC time with a specified precision. However, all operations are performed in the current session’s time zone, controlled by the TIMEZONE session parameter.

TIMESTAMP_TZ internally stores UTC time together with an associated time zone offset. When a time zone is not provided, the session time zone offset is used. All operations are performed with the time zone offset specific to each record.

Postgres:

All timezone-aware dates and times are stored internally in UTC.

So the underlying value should be UTC. I think you'll have to look at what their JDBC driver specifically does, though: it might localize the value for you. I think you may need database-specific converters?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmmm maybe we can change the consumer to do something smarter than getTimestamp. This SO suggests OffsetDateTime odt = myResultSet.getObject( … , OffsetDateTime.class ) ; .

So for TZ aware timestamps we could use ^ and if no offset is available assume UTC. I think that would work for most things, but it'd get tricky for something like TIMESTAMP_LTZ. I wonder how that even comes across through the JDBC driver? I imagine it's still of type TIMESTAMP_WITH_TIMEZONE just like TIMESTAMP_TZ. We might want to add the value from rsmd.getColumnTypeName to the JdbcFieldInfo as well so users can disambiguate between the two if they need to write a custom converter.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I ran into the same issue: #35916

So agreed, we need more info than what JdbcFieldInfo has. (ADBC's Java adapter already has a workaround to add the extra fields.) And yeah, I think trying to get OffsetDateTime or similar would be better.

That's part of why I want to vendor this into the ADBC driver, iterate on it + test it against actual databases, and then maybe send the changes back...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cool makes sense. I'll try to modify the consumer to do something smarter and correctly convert values into UTC.

I'll make a separate PR to add more data into JdbcFieldInfo.

WRT I want to vendor this into the ADBC driver... and then maybe send the changes back you mean redesign the JDBC to Arrow conversion within ADBC and eventually pull that back out into the arrow-jdbc package?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah. Though realistically, I don't have the time to do that right now so thank you for fixing up these things 😅

return new ArrowType.Timestamp(TimeUnit.MILLISECOND, timezone);
case Types.BINARY:
case Types.VARBINARY:
Expand Down Expand Up @@ -473,7 +470,7 @@ static JdbcConsumer getConsumer(ArrowType arrowType, int columnIndex, boolean nu
case Time:
return TimeConsumer.createConsumer((TimeMilliVector) vector, columnIndex, nullable, calendar);
case Timestamp:
if (config.getCalendar() == null) {
if (((ArrowType.Timestamp) arrowType).getTimezone() == null) {
return TimestampConsumer.createConsumer((TimeStampMilliVector) vector, columnIndex, nullable);
} else {
return TimestampTZConsumer.createConsumer((TimeStampMilliTZVector) vector, columnIndex, nullable, calendar);
Expand Down