Skip to content

Conversation

@samikshya-db
Copy link
Collaborator

@samikshya-db samikshya-db commented Nov 30, 2025

Description

Fixes #1116

Testing

Additional Notes to the Reviewer

x = new Timestamp(x.getTime());
x.setNanos(originalNanos);
TimeZone.setDefault(originalTimeZone);
setObject(parameterIndex, x, DatabricksTypeUtil.TIMESTAMP);
Copy link

@AndreiRudkouski AndreiRudkouski Dec 1, 2025

Choose a reason for hiding this comment

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

The current implementation of public void setTimestamp(int parameterIndex, Timestamp x, Calendar cal) throws SQLException method is dangerous because it temporarily changes the global JVM default time zone, which can break other threads and cause race conditions. However, this code is also logically incorrect: changing the default time zone does not affect the numeric value of a Timestamp, because Timestamp always stores an absolute UTC-based instant (long milliseconds). As a result, the method introduces global side effects without actually achieving its intended purpose.

If time zone adjustment is needed, you should compute the offset manually instead of modifying the global default:

long millis = x.getTime();

long adjustedMillis =
        millis
        - cal.getTimeZone().getOffset(millis)
        + TimeZone.getDefault().getOffset(millis);

Timestamp safeTs = new Timestamp(adjustedMillis);
safeTs.setNanos(x.getNanos());

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[BUG] DatabricksPreparedStatement#setTimestamp(int, java.sql.Timestamp, java.util.Calendar) truncates microseconds part

2 participants