I am using node.js client library and normally for every other symbol I am getting "timestamp" data properly but for NIFTY (Instrument = 256265), It gives me 1970 date.
@wtdmarketing We just installed fresh kiteconnect node.js client using npm install kiteconnect and tested your above code, timestamp returned to us is current_timestamp.Check below response:
Is there any change from your side since around 26th Jan 2020? I think there is something wrong with the exchange timestamp that I receive in nifty quote around that date. Can you please confirm?
@wtdmarketing We didn't get your query clearly. Are you using Websocket streaming to generate a minute candle at your end? We relay WebSocket data as we get from exchange.
The candle data generated using the live market data provided via the internet will not match when the same data is dumped on two machines. It will be near but not the same. You can refer to this thread.
We use the system time while creating candles and not the tick timestamp. You can know more here.
The candle data generated using the live market data provided via the internet will not match when the same data is dumped on two machines. --> I don't think this is true statement. If you use source timestamp, candles generated anywhere in the world.. any different machines will be the always same.
We use the system time while creating candles and not the tick timestamp. --> Again, I don't think this is true. If you guys are using your server's system time to generate candles then how come LIVE chart on your site (when market is open) is exactly matching with NSE website data? Do you think there is no (not even microseconds) delay between NSE servers and yours?
And moreover, this problem started only since last few days, it was perfect before then.
Is there any way I can talk to your technical team over the phone? This is really critical for me.
The ticks broadcasted from us for API clients as well as the kite frontend sends the latest tick for an instrument in a broadcast cycle (sub-second). You can think of it as a snapshot for that cycle.
It is not possible to recreate the same candles on charts as the charts consume the raw stream from the exchange. Do note that exchanges themselves don't stream all ticks to everyone and packet losses are to be expected over the internet even if one is using tick-by-tick stream. So, the charts themselves are mostly correct, not absolutely correct. This is one the reasons why charts across different platforms mostly match but not exactly. Nithin wrote about this here.
Regarding the timestamp used for forming charts, we use the exchange timestamp and if needed (same timestamp cases) we maintain ordering using system time.
A way to generate more accurate candles using the API would be to aggregate the candles using OHLC data from the tick. This could still miss open and close as the aggregates depend on ordering in the internal stream not the one that is broadcasted, but the high and low will always match.
Hope things are clear. Let us know if anything isn't.
Can you let us know, which API call you are making?Are youmaking OHLC API call?
I found the issue, It's in the Ticker library (node.js version).
https://github.com/zerodhatech/kiteconnectjs/blob/kite3/lib/ticker.js
Line #545 Javascript Date object requires milliseconds as input, so it should be: Hope this helps. Looking forward for updated library.
npm install kiteconnect
The github link I posted above, I got from your documentation page:
https://kite.trade/docs/connect/v3/#libraries-and-resources
We just installed fresh kiteconnect node.js client using
npm install kiteconnect
and tested your above code, timestamp returned to us is current_timestamp.Check below response: You might be using older version of client.Can you do npmshow kiteconnect version
and let us know the version, you are using?Is there any change from your side since around 26th Jan 2020? I think there is something wrong with the exchange timestamp that I receive in nifty quote around that date. Can you please confirm?
Any updates? This is causing me lots of issue and loss as well.
We didn't get your query clearly. Are you using Websocket streaming to generate a minute candle at your end?
We relay WebSocket data as we get from exchange.
It looks like "timestamp" field is not representing exchange timestamp, may be it's using your server's timestamp instead of exchanges? possible?
Please refer to my earlier post with screenshot.
Is there anyway we can talk over the phone so I can explain it better?
We use the system time while creating candles and not the tick timestamp.
You can know more here.
--> I don't think this is true statement. If you use source timestamp, candles generated anywhere in the world.. any different machines will be the always same.
We use the system time while creating candles and not the tick timestamp.
--> Again, I don't think this is true. If you guys are using your server's system time to generate candles then how come LIVE chart on your site (when market is open) is exactly matching with NSE website data? Do you think there is no (not even microseconds) delay between NSE servers and yours?
And moreover, this problem started only since last few days, it was perfect before then.
Is there any way I can talk to your technical team over the phone? This is really critical for me.
The ticks broadcasted from us for API clients as well as the kite frontend sends the latest tick for an instrument in a broadcast cycle (sub-second). You can think of it as a snapshot for that cycle.
It is not possible to recreate the same candles on charts as the charts consume the raw stream from the exchange. Do note that exchanges themselves don't stream all ticks to everyone and packet losses are to be expected over the internet even if one is using tick-by-tick stream. So, the charts themselves are mostly correct, not absolutely correct. This is one the reasons why charts across different platforms mostly match but not exactly.
Nithin wrote about this here.
Regarding the timestamp used for forming charts, we use the exchange timestamp and if needed (same timestamp cases) we maintain ordering using system time.
A way to generate more accurate candles using the API would be to aggregate the candles using OHLC data from the tick. This could still miss open and close as the aggregates depend on ordering in the internal stream not the one that is broadcasted, but the high and low will always match.
Hope things are clear. Let us know if anything isn't.
Could you please help to explain the difference between kite3 branch and master branch.
Are you able to build candles at your end accurately, I mean Open and Close are exactly matching with Kite?
Thanks in advance for your quick response.
- 3.1.0