SNOW-1714049: getTime losing nanosecond values from 3.13.31

[akanimesh7]

Please answer these questions before submitting your issue.
In order to accurately debug the issue this information is required. Thanks!

1. What version of JDBC driver are you using?

3.13.30 and 3.13.31

2. What operating system and processor architecture are you using?
   macOS, arm64

3. What version of Java are you using?
   openjdk version "17.0.5" 2022-10-18

4. What did you do?

   Connection conn = getConnection();
    Statement stmt = conn.createStatement();
    stmt.executeQuery("ALTER SESSION SET JDBC_QUERY_RESULT_FORMAT='JSON'");
    stmt.executeQuery("CREATE OR REPLACE TABLE TEST_TIME(TIME_COL TIME)");
    stmt.executeQuery("INSERT INTO TEST_TIME VALUES ('12:34:56.123456789')");
    ResultSet rs = stmt.executeQuery("SELECT * FROM TEST_TIME");
    ResultSetMetaData rsmd = rs.getMetaData();
    System.out.println(rsmd.getColumnClassName(1));
    while (rs.next()) {
      System.out.println(rs.getObject(1).getClass());
      System.out.println(((SnowflakeTimeWithTimezone)rs.getObject(1)).getNano());
      System.out.println(rs.getTime(1));
    }
    rs.close();
    stmt.close();
    conn.close();

5. What did you expect to see?

In 3.13.0, this returns

java.sql.Time
class net.snowflake.client.jdbc.SnowflakeTimeWithTimezone
123456789
12:34:56

While in 3.13.1
This returns

java.sql.Time
class java.sql.Time
Exception in thread "main" java.lang.ClassCastException: class java.sql.Time cannot be cast to class net.snowflake.client.jdbc.SnowflakeTimeWithTimezone (java.sql.Time is in module java.sql of loader 'platform'; net.snowflake.client.jdbc.SnowflakeTimeWithTimezone is in unnamed module of loader 'app')
	at io.animesh.snowflake.SnowflakeExample.issueCode(SnowflakeExample.java:43)
	at io.animesh.snowflake.SnowflakeExample.main(SnowflakeExample.java:29)

What this means is now instead of SnowflakeTimeWithTimezone which contained info about nanos, java.sql.Time is being used, which on the other hand only stores upto seconds granularity.

The reason for this seems to be this PR -- #1383

[akanimesh7]

@sfc-gh-wfateem Any updates on this ?