Skip to content

GH-35138: [Java] Fix ArrowFlightJdbcTimeStampVectorAccessor to deal with calendar #35139

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

Closed
wgtmac wants to merge 1 commit into from
Closed

GH-35138: [Java] Fix ArrowFlightJdbcTimeStampVectorAccessor to deal with calendar #35139

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
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
2 changes: 1 addition & 1 deletion ...ache/arrow/driver/jdbc/accessor/impl/calendar/ArrowFlightJdbcTimeStampVectorAccessor.java
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -96,7 +96,7 @@ private LocalDateTime getLocalDateTime(Calendar calendar) {
TimeZone timeZone = calendar.getTimeZone();
long millis = this.timeUnit.toMillis(value);
localDateTime = localDateTime
.minus(timeZone.getOffset(millis) - this.timeZone.getOffset(millis), ChronoUnit.MILLIS);
.plus(timeZone.getOffset(millis) - this.timeZone.getOffset(millis), ChronoUnit.MILLIS);
Copy link
Member Author

@wgtmac wgtmac Apr 16, 2023

Choose a reason for hiding this comment

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

The original buggy code I want to solve is here. It tries to convert local date time from vector timezone to user-supplied timezone. We should add the timezone offset but not subtract it. A number of test cases need to be fixed as their expected values are computed with the same issue.

}
return localDateTime;
}
Expand Down
4 changes: 2 additions & 2 deletions .../flight-sql-jdbc-core/src/main/java/org/apache/arrow/driver/jdbc/utils/DateTimeUtils.java
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -36,7 +36,7 @@ private DateTimeUtils() {
}

/**
* Subtracts given Calendar's TimeZone offset from epoch milliseconds.
* Adds given Calendar's TimeZone offset from epoch milliseconds.
*/
public static long applyCalendarOffset(long milliseconds, Calendar calendar) {
if (calendar == null) {
Expand All @@ -47,7 +47,7 @@ public static long applyCalendarOffset(long milliseconds, Calendar calendar) {
final TimeZone defaultTz = TimeZone.getDefault();

if (tz != defaultTz) {
milliseconds -= tz.getOffset(milliseconds) - defaultTz.getOffset(milliseconds);
milliseconds += tz.getOffset(milliseconds) - defaultTz.getOffset(milliseconds);
Copy link
Member Author

@wgtmac wgtmac Apr 16, 2023

Choose a reason for hiding this comment

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

The problem is that I made this line of change in order to fix the test failures of this case:

arrow/java/flight/flight-sql-jdbc-core/src/test/java/org/apache/arrow/driver/jdbc/accessor/impl/calendar/ArrowFlightJdbcTimeStampVectorAccessorTest.java

Line 292 in eaa1a1e

public void testShouldGetStringBeConsistentWithVarCharAccessorWithCalendar() throws Exception {
and let me paste the code snippet of that case below:

  @Test
  public void testShouldGetStringBeConsistentWithVarCharAccessorWithCalendar() throws Exception {
    // Ignore for TimeStamp vectors with TZ, as VarChar accessor won't consider their TZ
    Assume.assumeTrue(
        vector instanceof TimeStampNanoVector || vector instanceof TimeStampMicroVector ||
            vector instanceof TimeStampMilliVector || vector instanceof TimeStampSecVector);
    Calendar calendar = Calendar.getInstance(TimeZone.getTimeZone(AMERICA_VANCOUVER));
    assertGetStringIsConsistentWithVarCharAccessor(calendar);
  }

  private void assertGetStringIsConsistentWithVarCharAccessor(Calendar calendar) throws Exception {
    try (VarCharVector varCharVector = new VarCharVector("",
        rootAllocatorTestRule.getRootAllocator())) {
      varCharVector.allocateNew(1);
      ArrowFlightJdbcVarCharVectorAccessor varCharVectorAccessor =
          new ArrowFlightJdbcVarCharVectorAccessor(varCharVector, () -> 0, (boolean wasNull) -> {
          });

      accessorIterator.iterate(vector, (accessor, currentRow) -> {
        final String string = accessor.getString();
        varCharVector.set(0, new Text(string));
        varCharVector.setValueCount(1);

        Timestamp timestampFromVarChar = varCharVectorAccessor.getTimestamp(calendar);
        Timestamp timestamp = accessor.getTimestamp(calendar);

        collector.checkThat(timestamp, is(timestampFromVarChar));
        collector.checkThat(accessor.wasNull(), is(false));
      });
    }
  }

Copy link
Member Author

@wgtmac wgtmac Apr 16, 2023

Choose a reason for hiding this comment

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

In the test above, the user-supplied timezone is AMERICA_VANCOUVER. When the input text to varCharVector is 2021-07-09 00:00:00.0, varCharVectorAccessor.getTimestamp(calendar) returns 2021-07-09 07:00:00.0. This does not make sense to me at all. @lidavidm

Copy link
Member Author

@wgtmac wgtmac Apr 16, 2023 •
edited
Loading

Choose a reason for hiding this comment

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

To summarize, we have two bugs for now.

  • conversion between time zones are incorrect.
  • It assumes utc if time zone is not set in the timestamp vector. Same for varchar vector if it tries to interpret as timestamp values.

For the fix of jdbc implementation of getDate/getTimestamp with a calendar as input, I’d propose following:

  • convert between timezones if timestamp vector has set timezone and user supplied calendar is not null.
  • Throw unsupported operation exception if vector does not have timezone set and user has provided a timezone. The reason is that the returned timestamp object cannot carry timezone info. Or return the timestamp as is to pretend it is in the user supplied timezone?

IIUC, the timezone info in your derby example comes from the SimpleDateFormat but not the resultset itself.

WDYT? @lidavidm

Copy link
Member

@lidavidm lidavidm Apr 16, 2023

Choose a reason for hiding this comment

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

varCharVectorAccessor.getTimestamp(calendar) returns 2021-07-09 07:00:00.0. This does not make sense to me at all.

That's midnight in Vancouver expressed as GMT so it's consistent with the other case described above.

conversion between time zones are incorrect.

It seems unintuitive, but at least consistent: it will take that date at midnight in the given time zone, and express it in GMT, which seems to match the docstring of java.sql.Date.

Throw unsupported operation exception if vector does not have timezone set and user has provided a timezone. The reason is that the returned timestamp object cannot carry timezone info. Or return the timestamp as is to pretend it is in the user supplied timezone?

That may also work, but I suppose if the user is explicitly passing a Calendar, the current behavior is what they actually want? This is more a flaw of the original Java date/time APIs in that Date itself doesn't carry the timezone so the display value is weird.

Copy link
Member Author

@wgtmac wgtmac Apr 17, 2023

Choose a reason for hiding this comment

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

Right, at least these behaviors are consistent to each other. It is unintuitive since timestamp values are always returned in the GMT regardless of what calendar is supplied. I cannot say this is wrong because it seems to be aligned with the SQL TIMESTAMP_WITH_TIMEZONE type.

There was a discussion in the Hadoop community to work on the consistency of timestamp semantics across different SQL-on-Hadoop engines. It proposed a TIMESTAMP_WITH_LOCAL_TIMEZONE type in addition to the SQL TIMESTAMP_WITHOUT_TIMEZONE and TIMESTAMP_WITH_TIMEZONE types:

  • SQL TIMESTAMP_WITHOUT_TIMEZONE: Always display the same wall clock time regardless of timezone.
  • SQL TIMESTAMP_WITH_TIMEZONE: The timestamp value is stored in a specific timezone (can be non-UTC) and can be converted to any timezone for display.
  • New TIMESTAMP_WITH_LOCAL_TIMEZONE: The timestamp value is stored in the UTC and always display it in the local timezone.

Most of the SQL engines in the aforementioned doc now support TIMESTAMP_WITH_LOCAL_TIMEZONE type and so do the open file formats like the Apache Parquet and Apache Orc. I made this PR to align the behavior with TIMESTAMP_WITH_LOCAL_TIMEZONE type. Nevertheless I am no an expert on JDBC so I am afraid that I may not know what is the expected behavior from the end users.

Please feel free to close this PR if you think the current behavior is not an issue, or involve more people to the discussion if a fix is required. Thanks for the discussion in detail!

Copy link
Member

@lidavidm lidavidm Apr 17, 2023

Choose a reason for hiding this comment

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

Thanks for bearing with me. The mess of date/time APIs here is confusing...

For Arrow: timestamp[s, TZ] appears equivalent to TIMESTAMP_WITH_LOCAL_TIMEZONE. Arrow always stores the underlying value in UTC. timestamp[s] appears to be TIMESTAMP_WITHOUT_TIMEZONE. Arrow does not have an equivalent to TIMESTAMP_WITH_TIMEZONE.

So the question here is still the semantics of getDate(int, Calendar). The method looks ill-defined to me if java.sql.Date is not supposed to carry time or timezone information in the first place...The API docs say "This method uses the given calendar to construct an appropriate millisecond value for the date if the underlying database does not store timezone information."

I do see things like this: https://stackoverflow.com/questions/9202857/timezones-in-sql-date-vs-java-sql-date

This means that when you work in UTC+1 and ask the database for a DATE a compliant implementation does exactly what you've observed: return a java.sql.Date with a milliseconds value that corresponds to the date in question at 00:00:00 UTC+1 independently of how the data got to the database in the first place.

So that also seems to match the existing behavior, by my reading.

I looked at Postgres's JDBC driver:

https://github.com/pgjdbc/pgjdbc/blob/3c3e5b62349c42d9d3dfe1fe0102776d4de8c353/pgjdbc/src/main/java/org/postgresql/jdbc/PgResultSet.java#L532

and

https://github.com/pgjdbc/pgjdbc/blob/3c3e5b62349c42d9d3dfe1fe0102776d4de8c353/pgjdbc/src/main/java/org/postgresql/jdbc/TimestampUtils.java#L639-L653

Truncate date part so in given time zone the date would be formatted as 00:00

I think that also matches with the current behavior, as unintuitive as it is.

Copy link
Member Author

@wgtmac wgtmac Apr 17, 2023

Choose a reason for hiding this comment

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

Thanks for the additional links! It is really a notorious topic :)

}

return milliseconds;
Expand Down
4 changes: 2 additions & 2 deletions ...pache/arrow/driver/jdbc/accessor/impl/calendar/ArrowFlightJdbcDateVectorAccessorTest.java
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -130,7 +130,7 @@ public void testShouldGetTimestampReturnValidTimestampWithCalendar() throws Exce

long offset = timeZone.getOffset(resultWithoutCalendar.getTime());

collector.checkThat(resultWithoutCalendar.getTime() - result.getTime(), is(offset));
collector.checkThat(result.getTime() - resultWithoutCalendar.getTime(), is(offset));
collector.checkThat(accessor.wasNull(), is(false));
});
}
Expand Down Expand Up @@ -160,7 +160,7 @@ public void testShouldGetDateReturnValidDateWithCalendar() throws Exception {

long offset = timeZone.getOffset(resultWithoutCalendar.getTime());

collector.checkThat(resultWithoutCalendar.getTime() - result.getTime(), is(offset));
collector.checkThat(result.getTime() - resultWithoutCalendar.getTime(), is(offset));
collector.checkThat(accessor.wasNull(), is(false));
});
}
Expand Down
6 changes: 3 additions & 3 deletions .../arrow/driver/jdbc/accessor/impl/calendar/ArrowFlightJdbcTimeStampVectorAccessorTest.java
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -182,7 +182,7 @@ public void testShouldGetTimestampReturnValidTimestampWithCalendar() throws Exce
long offset = timeZone.getOffset(resultWithoutCalendar.getTime()) -
timeZoneForVector.getOffset(resultWithoutCalendar.getTime());

collector.checkThat(resultWithoutCalendar.getTime() - result.getTime(), is(offset));
collector.checkThat(result.getTime() - resultWithoutCalendar.getTime(), is(offset));
collector.checkThat(accessor.wasNull(), is(false));
});
}
Expand Down Expand Up @@ -215,7 +215,7 @@ public void testShouldGetDateReturnValidDateWithCalendar() throws Exception {
long offset = timeZone.getOffset(resultWithoutCalendar.getTime()) -
timeZoneForVector.getOffset(resultWithoutCalendar.getTime());

collector.checkThat(resultWithoutCalendar.getTime() - result.getTime(), is(offset));
collector.checkThat(result.getTime() - resultWithoutCalendar.getTime(), is(offset));
collector.checkThat(accessor.wasNull(), is(false));
});
}
Expand Down Expand Up @@ -248,7 +248,7 @@ public void testShouldGetTimeReturnValidTimeWithCalendar() throws Exception {
long offset = timeZone.getOffset(resultWithoutCalendar.getTime()) -
timeZoneForVector.getOffset(resultWithoutCalendar.getTime());

collector.checkThat(resultWithoutCalendar.getTime() - result.getTime(), is(offset));
collector.checkThat(result.getTime() - resultWithoutCalendar.getTime(), is(offset));
collector.checkThat(accessor.wasNull(), is(false));
});
}
Expand Down
4 changes: 2 additions & 2 deletions ...pache/arrow/driver/jdbc/accessor/impl/calendar/ArrowFlightJdbcTimeVectorAccessorTest.java
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -137,7 +137,7 @@ public void testShouldGetTimestampReturnValidTimestampWithCalendar() throws Exce

long offset = timeZone.getOffset(resultWithoutCalendar.getTime());

collector.checkThat(resultWithoutCalendar.getTime() - result.getTime(), is(offset));
collector.checkThat(result.getTime() - resultWithoutCalendar.getTime(), is(offset));
collector.checkThat(accessor.wasNull(), is(false));
});
}
Expand Down Expand Up @@ -170,7 +170,7 @@ public void testShouldGetTimeReturnValidTimeWithCalendar() throws Exception {

long offset = timeZone.getOffset(resultWithoutCalendar.getTime());

collector.checkThat(resultWithoutCalendar.getTime() - result.getTime(), is(offset));
collector.checkThat(result.getTime() - resultWithoutCalendar.getTime(), is(offset));
collector.checkThat(accessor.wasNull(), is(false));
});
}
Expand Down
60 changes: 43 additions & 17 deletions ...apache/arrow/driver/jdbc/accessor/impl/text/ArrowFlightJdbcVarCharVectorAccessorTest.java
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -510,14 +510,23 @@ public void testShouldGetDateReturnValidDateWithCalendar() throws Exception {
Text value = new Text("2021-07-02");
when(getter.get(0)).thenReturn(value.copyBytes());

Calendar calendar = Calendar.getInstance(TimeZone.getTimeZone("America/Sao_Paulo"));
Date result = accessor.getDate(calendar);
{
Calendar calendar = Calendar.getInstance(TimeZone.getTimeZone("America/Sao_Paulo"));
Date result = accessor.getDate(calendar);
calendar.setTime(result);

calendar = Calendar.getInstance(TimeZone.getTimeZone("Etc/UTC"));
calendar.setTime(result);
collector.checkThat(dateTimeFormat.format(calendar.getTime()),
equalTo("2021-07-01T21:00:00.000Z"));
Comment on lines +518 to +519
Copy link
Member

@lidavidm lidavidm Apr 15, 2023

Choose a reason for hiding this comment

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

OK. So the assumption is that the underlying value is in UTC, and are converting to the destination time zone?

Derby does something different, though:

    SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss.SSSXXX");
    try (final Connection connection = DriverManager.getConnection("jdbc:derby:memory:foo;create=true")) {
      try (final Statement statement = connection.createStatement()) {
        statement.executeUpdate("CREATE TABLE foo (bar DATE)");
        statement.executeUpdate("INSERT INTO foo (bar) VALUES '2021-07-02'");
        try (final ResultSet rs = statement.executeQuery("SELECT * FROM foo")) {
          assertThat(rs.next()).isTrue();
          Calendar calendar = Calendar.getInstance(TimeZone.getTimeZone("America/Sao_Paulo"));
          final Date date = rs.getDate(1, calendar);
          System.out.println(date);
          calendar.setTime(date);
          System.out.println(sdf.format(calendar.getTime()));
        }
      }
    }

Derby appears to just attach the timezone to the value, instead of adjusting it from an assumed source time zone. The output is:

2021-07-02
2021-07-02T12:00:00.000+09:00

Copy link
Member Author

@wgtmac wgtmac Apr 15, 2023 •
edited
Loading

Choose a reason for hiding this comment

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

So the assumption is that the underlying value is in UTC, and are converting to the destination time zone?

It depends on the whether the timezone field is set in the TimeStampVector.

  • If timezone is not set, it assumes UTC and converts from that to target timezone.
  • If timezone is set, it converts from the vector-provided timezone to target timezone.

If user does not request a different timezone, then the result is good. Otherwise the problem emerges.

Copy link
Member

@lidavidm lidavidm Apr 15, 2023

Choose a reason for hiding this comment

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

If timezone is not set, it assumes UTC and converts from that to target timezone.

This seems a bit off though, since we don't know the timezone in that case specifically. (Not that the current behavior seems any better!) It seems like the right behavior here would be to either treat this as an error, or behave like Derby and treat the user-supplied calendar to mean, "assume the timestamp is a timestamp as viewed in this time zone".

Copy link
Member Author

@wgtmac wgtmac Apr 15, 2023

Choose a reason for hiding this comment

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

Here is the code where it assumes UTC if timezone is missing from the vector:

arrow/java/flight/flight-sql-jdbc-core/src/main/java/org/apache/arrow/driver/jdbc/accessor/impl/calendar/ArrowFlightJdbcTimeStampVectorAccessor.java

Line 180 in eaa1a1e

return TimeZone.getTimeZone("UTC");

Yes, I agree with you that we shouldn't blindly assume timezone to be UTC if unset. In Apache Hive, this usually means timestamp without timezone where the values are assumed to be in the default timezone in the JVM (which is the local timezone in the usual case).

Copy link
Member Author

@wgtmac wgtmac Apr 15, 2023

Choose a reason for hiding this comment

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

IMO, any behavior change may need a discussion as it will affect downstream users. This patch only focuses on the bug fix.

Copy link
Member

@lidavidm lidavidm Apr 16, 2023

Choose a reason for hiding this comment

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

Fair, though arguably this is replacing buggy behavior with buggy behavior 🙂

Let's put a caveat in the documentation page for the driver?

We should consider aligning with what Derby appears to do, too. Either that, or check a few other drivers to see the expected behavior here.

I'm still not sure the conversion here is correct, though. From the docs, java.sql.Date is the millisecond value (in GMT) of midnight of a date in some time zone.

So if we have the date "2021-07-02" in America/Sao_Paulo, then the GMT timestamp should be 2021-07-02 03:00. So the new behavior doesn't seem correct and the old behavior is what's expected.

Or if we are assuming that the date is "2021-07-02" in UTC, and converting that to Sao Paulo, that makes no sense - Date isn't supposed to store a time, so we shouldn't treat it as one.

Copy link
Member Author

@wgtmac wgtmac Apr 16, 2023

Choose a reason for hiding this comment

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

The accessor.getDate(calendar) above is to implement ResultSet.getDate(int, Calendar) and returns a java.sq.Date. Given two facts:

  • java.sql.Date: A milliseconds value represents the number of milliseconds that have passed since January 1, 1970 00:00:00.000 GMT. To conform with the definition of SQL DATE, the millisecond values must be 'normalized' by setting the hours, minutes, seconds, and milliseconds to zero in the particular time zone with which the instance is associated.
  • ResultSet.getDate(int, Calendar): Retrieves the value of the designated column in the current row of this ResultSet object as a java.sql.Date object in the Java programming language. This method uses the given calendar to construct an appropriate millisecond value for the date if the underlying database does not store timezone information.

Therefore I agree with you that we should assume the underlying values we are reading do not have timezone information and the behavior would be much easier to understand if we simply attach the user-supplied timezone to the values to return.

The original buggy code that this PR tries to solve actually is not here. The modification here was a result of that fix. Please see my other comments above. Let me double check if there is something wrong.

Copy link
Member

@lidavidm lidavidm Apr 16, 2023

Choose a reason for hiding this comment

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

The original buggy code that this PR tries to solve actually is not here.

Right, I'm just trying to use this to understand what's happening here.

}

collector.checkThat(dateTimeFormat.format(calendar.getTime()),
equalTo("2021-07-02T03:00:00.000Z"));
{
Calendar calendar = Calendar.getInstance(TimeZone.getTimeZone("Etc/UTC"));
Date result = accessor.getDate(calendar);
calendar.setTime(result);

collector.checkThat(dateTimeFormat.format(calendar.getTime()),
equalTo("2021-07-02T00:00:00.000Z"));
}
}

@Test
Expand Down Expand Up @@ -547,13 +556,21 @@ public void testShouldGetTimeReturnValidDateWithCalendar() throws Exception {
Text value = new Text("02:30:00");
when(getter.get(0)).thenReturn(value.copyBytes());

Calendar calendar = Calendar.getInstance(TimeZone.getTimeZone("America/Sao_Paulo"));
Time result = accessor.getTime(calendar);
{
Calendar calendar = Calendar.getInstance(TimeZone.getTimeZone("America/Sao_Paulo"));
Time result = accessor.getTime(calendar);
calendar.setTime(result);

calendar = Calendar.getInstance(TimeZone.getTimeZone("Etc/UTC"));
calendar.setTime(result);
collector.checkThat(timeFormat.format(calendar.getTime()), equalTo("23:30:00.000Z"));
}

collector.checkThat(timeFormat.format(calendar.getTime()), equalTo("05:30:00.000Z"));
{
Calendar calendar = Calendar.getInstance(TimeZone.getTimeZone("Etc/UTC"));
Time result = accessor.getTime(calendar);
calendar.setTime(result);

collector.checkThat(timeFormat.format(calendar.getTime()), equalTo("02:30:00.000Z"));
}
}

@Test
Expand Down Expand Up @@ -584,14 +601,23 @@ public void testShouldGetTimestampReturnValidDateWithCalendar() throws Exception
Text value = new Text("2021-07-02 02:30:00.000");
when(getter.get(0)).thenReturn(value.copyBytes());

Calendar calendar = Calendar.getInstance(TimeZone.getTimeZone("America/Sao_Paulo"));
Timestamp result = accessor.getTimestamp(calendar);
{
Calendar calendar = Calendar.getInstance(TimeZone.getTimeZone("America/Sao_Paulo"));
Timestamp result = accessor.getTimestamp(calendar);
calendar.setTime(result);

calendar = Calendar.getInstance(TimeZone.getTimeZone("Etc/UTC"));
calendar.setTime(result);
collector.checkThat(dateTimeFormat.format(calendar.getTime()),
equalTo("2021-07-01T23:30:00.000Z"));
}

collector.checkThat(dateTimeFormat.format(calendar.getTime()),
equalTo("2021-07-02T05:30:00.000Z"));
{
Calendar calendar = Calendar.getInstance(TimeZone.getTimeZone("Etc/UTC"));
Timestamp result = accessor.getTimestamp(calendar);
calendar.setTime(result);

collector.checkThat(dateTimeFormat.format(calendar.getTime()),
equalTo("2021-07-02T02:30:00.000Z"));
}
}

private void assertGetBoolean(Text value, boolean expectedResult) throws SQLException {
Expand Down
2 changes: 1 addition & 1 deletion ...ght-sql-jdbc-core/src/test/java/org/apache/arrow/driver/jdbc/utils/DateTimeUtilsTest.java
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -67,7 +67,7 @@ public void testShouldGetOffsetWithDifferentTimeZone() {
TimeZone.setDefault(alternateTimezone);

try { // Trying to guarantee timezone returns to its original value
final long expectedEpochMillis = epochMillis + offset;
final long expectedEpochMillis = epochMillis - offset;
final long actualEpochMillis = DateTimeUtils.applyCalendarOffset(epochMillis, Calendar.getInstance(
defaultTimezone));

Expand Down