SNOW-1980317: SFArrowResult set is not honoring TreatNTZAsUTC

[akanimesh7]

https://github.com/snowflakedb/snowflake-jdbc/blob/v3.22.0/src/main/java/net/snowflake/client/core/SFArrowResultSet.java#L558-L565

Version in consideration - v3.22.0

The converter created in the above method sets sessionTimezone, but it doesn't set the treatNTZAsUTC. Is there any reason for that ?

As of today, if i want to get the value present in a TIMESTAMP_NTZ column exactly as-is in UTC , which is what i assume JDBC_TREAT_TIMESTAMP_NTZ_AS_UTC does, is there a way ? This question is in context of using SFArrowResultSet. I am able to get this working with SFJsonResultSet using the below --

    properties.put("CLIENT_TIMESTAMP_TYPE_MAPPING", "TIMESTAMP_NTZ");
    properties.put("JDBC_TREAT_TIMESTAMP_NTZ_AS_UTC", "true");
    properties.put("JDBC_USE_SESSION_TIMEZONE", "false");

[sfc-gh-dszmolka]

hello - JDBC_USE_SESSION_TIMEZONE if false, then the driver uses the JVM's timezone for _NTZ type data.
Unfortunately enough, there's further parameters which are considered in determining what timezone will be used after all, such as
JDBC_FORMAT_DATE_WITH_TIMEZONE (by default true) and TIMEZONE

Which I believe should be no issue if you anyways use JDBC_USE_SESSION_TIMEZONE=false to rely to using local JVM clock instead of Snowflake session's clock.

I'm wondering if your test works if you ALTER SESSION SET TIMEZONE='UTC' first? (or in a more permanent way like ALTER USER or ALTER ACCOUNT)

Do you perhaps have a reproduction which you can share?

[akanimesh7]

Sure. Here is the repro model.

public class SnowflakeRepro {
  public static void main(String[] args) throws SQLException {
    Connection connection = getConnection();
    Statement stmt = connection.createStatement();
    stmt.executeQuery("ALTER SESSION SET JDBC_QUERY_RESULT_FORMAT='JSON'");

    ResultSet rs = stmt.executeQuery("SELECT CURRENT_TIMESTAMP::TIMESTAMP_NTZ");
    while (rs.next()){
      System.out.println(rs.getTimestamp(1).toInstant());
    }

  }
  private static Connection getConnection() throws SQLException {

    // build connection properties
    Properties properties = new Properties();
    properties.put("user", "<>"); // replace "" with your user name
    properties.put("password", "<>"); // replace "" with your password
    properties.put("warehouse", "<>"); // replace "" with target warehouse name
    properties.put("db", "<>"); // replace "" with target database name
    properties.put("schema", "<>"); // replace "" with target schema name
    properties.put("CLIENT_TIMESTAMP_TYPE_MAPPING", "TIMESTAMP_NTZ");
    properties.put("JDBC_TREAT_TIMESTAMP_NTZ_AS_UTC", "true");
    properties.put("JDBC_USE_SESSION_TIMEZONE", "false");

    
    String connectStr = "jdbc:snowflake://<>.snowflakecomputing.com";
    return DriverManager.getConnection(connectStr, properties);
  }
}

This is printing the exact same timestamp as is printed on the snowflake instance when using the query SELECT CURRENT_TIMESTAMP::TIMESTAMP_NTZ but in UTC timezone.

I want this behavior to be replicated with the Arrow Result set.

[akanimesh7]

More info

• Timezone as queried with SHOW PARAMETERS LIKE '%TIMEZONE%'; is America/Los_Angeles
• Current timestamp as queried with SELECT CURRENT_TIMESTAMP::TIMESTAMP_NTZ is 2025-03-13 02:46:43.368

In the above repro model, if i remove any one of the params JDBC_TREAT_TIMESTAMP_NTZ_AS_UTC or JDBC_USE_SESSION_TIMEZONE. I end up getting my timezone adjusted timestamp.

[akanimesh7]

Can you also check this ?

The converter created in the above method sets sessionTimezone, but it doesn't set the treatNTZAsUTC. Is there any reason for that ?

[akanimesh7]

@sfc-gh-dszmolka Can you review and help ?

[sfc-gh-dszmolka]

Thank you for your patience here @akanimesh7 ! Please know, that I'm doing my best to follow up with all issues in all repositories we have, but as seen in the README this is best effort.
If you have a crippling urgent issue which is hampering your business critical flows, do file an official case with Snowflake Support, which has all kinds of SLA's attached to it. Thank you for understanding.