Documenting Observations - Kite Connect Java Client from Zerodha

The idea behind this thread is to document what I am seeing while working with the Kite Connect Java Client in terms of how it behaves. That is what values it is returning under different conditions.

Would request all users to add their observations for the benefit of the wider community. This is particularly important given the dismal state of documentation of the Java client.

Ticks WebSocket Timestamps

• Tick Timestamp and Last Traded Time are both returned at second resolution.
  

From KiteTicker.java
long lastTradedtime = convertToLong(getBytes(bin, 44, 48)) * 1000;
if(isValidDate(lastTradedtime)) {
tick.setLastTradedTime(new Date(lastTradedtime));
} else {
tick.setLastTradedTime(null);
}

and

/* Convert binary data to long datatype*/
private long convertToLong(byte[] bin){
ByteBuffer bb = ByteBuffer.wrap(bin);
bb.order(ByteOrder.BIG_ENDIAN);
return bb.getInt();
}

In KiteTicker.java, Zerodha is using bb.getInt() and returning a "long". Assuming that the original JSON response has the millisecond data, this will lose data and we see that the value returned by the convertToLong() method is multiplied by 1000 to get a long to use as lastTradedTime.

The Zerodha code effectively throws away the millisecond information and truncates the time to "second" level resolution.

@ToDo Double check the JSON response data to see if Zerodha is sending the millisecond data from the server.