git.net

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[jira] [Created] (CALCITE-2743) TimeStamp confused in avatica jdbc


shining created CALCITE-2743:
--------------------------------

             Summary: TimeStamp confused in avatica jdbc
                 Key: CALCITE-2743
                 URL: https://issues.apache.org/jira/browse/CALCITE-2743
             Project: Calcite
          Issue Type: Bug
          Components: avatica
    Affects Versions: 1.10.0
            Reporter: shining


I use Phoenix Query Server through avatica, Operation is as follows:

1. create table with sqlline-thin
   
    CREATE TABLE test_timezone(log_time TIMESTAMP NOT NULL PRIMARY KEY, id VARCHAR(40));

2. Upset data
    
     upsert into test_timezone values('2018-11-27 11:01:59.000','1’);

3. Query
     0: jdbc:phoenix:thin:url=http://localhost:876> select * from test_timezone;
    +------------------------------+-----+
     |       LOG_TIME           | ID   |
    +-----------------------------+------+
     | 2018-11-27 03:01:59  | 1     |
    +------------------------------+——+

My local timeZone is GMT+8, and configured Phoenix “phoenix.query.dateFormatTimeZone=GMT+8”

I also view code of avatica, when the timezone is GMT+8, getTimeStamp method will lose 8 hours:
 public Timestamp getTimestamp(Calendar calendar) throws SQLException {
  java.util.Date date  = (java.util.Date) getObject();
  if (date == null) {
    return null;
  }
  long v = date.getTime();
  if (calendar != null) {
    v -= calendar.getTimeZone().getOffset(v);
  }
  return new Timestamp(v);
}
sqlline-thin use getString() method get the timestamp,it pass a null timezone to timestampAsString() 

So I have two doubtful places here:

1)I get correct time from phoenixResultSet, why reduce 8 hours ?
2)Can getString method  be returned by getTimeStamp().toString():
      public String getString() throws SQLException {
  final long v = getLong();
  if (v == 0 && wasNull()) {
    return null;
  }
  return getTimeStamp(v, null).toString();
}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)