I’m adding a timestamp in my code, but there’s a discrepancy between my script's timestamp and Zerodha’s execution timing—probably due to server latency. Is there a way to sync my script with Zerodha’s server time?
@nivas I'm not referring to the execution time specifically—I just want to capture the exact timestamp at which Zerodha places the order and reflect that in my code. For example, if a trade is placed at 12:41:31 according to Zerodha, my code currently shows 12:41:34.
Is there a way to get the exact same timestamp as Zerodha's in my code?
@Walker You don't get an exact answer from them, though I have already enquired many times. There is a phenomenon that only the Kite team doesn't know about or is pretending to be unaware of: the tick delay. It doesn't mean so-called "latency". If we raise some questions, they will only repeatedly talk about the latency and NSE colocation. Unfortunately, they were charging 2000 rs per month for this delayed data, while other brokers were charging zero with no tick delay. Other brokers don't call this inefficiency as "latency or colocation".
"Retail WebSocket tick delay and colocation latency are totally different concepts."
Building a rocket with ISRO is much easier than understanding the tick delay issues with them.
For a highly liquid instrument, the exchange will send out snapshot ticks at exactly the same time every second, hence "the current time (second) should be equal with the exchange time (second)" is the logic. That is the logic, and a child may be able to understand it.
For an illiquid instrument, you may not get ticks every second, which means the exchange isn't sending out the ticks to broadcast channels. That is okay; it is not an issue of the broker. This is exactly why they can't agree that they are depending on multiple sources for data, and it causes this delay. To be very clear, Zerodha tick data is delayed by 1 to 2 seconds therefore, as traders, we only know the price of an instrument after 1 to 2 seconds.
If you want to know the price of an instrument or place an order (order placing and executing are totally different concepts) at the exact time, only after an average of 80-150 ms, which is normal for retail APIs. Kite API is not good for that purpose until they fix this issue. Try some other API like Finavasia or TD or GDFL or even Fyers. TD and GDFL are data vendors; they are data providers. You can't place orders.
You may check your log reports or DB logs for the delay; most of the people don't know about this issue; they still believe it's a clock drift issue or an AWS server issue, etc.
Hopefully they may change their infrastructure; I am waiting for that moment.
Is there a way to get the exact same timestamp as Zerodha's in my code?
"Retail WebSocket tick delay and colocation latency are totally different concepts."
Building a rocket with ISRO is much easier than understanding the tick delay issues with them.
For a highly liquid instrument, the exchange will send out snapshot ticks at exactly the same time every second, hence "the current time (second) should be equal with the exchange time (second)" is the logic. That is the logic, and a child may be able to understand it.
For an illiquid instrument, you may not get ticks every second, which means the exchange isn't sending out the ticks to broadcast channels. That is okay; it is not an issue of the broker.
This is exactly why they can't agree that they are depending on multiple sources for data, and it causes this delay. To be very clear, Zerodha tick data is delayed by 1 to 2 seconds therefore, as traders, we only know the price of an instrument after 1 to 2 seconds.
If you want to know the price of an instrument or place an order (order placing and executing are totally different concepts) at the exact time, only after an average of 80-150 ms, which is normal for retail APIs. Kite API is not good for that purpose until they fix this issue. Try some other API like Finavasia or TD or GDFL or even Fyers. TD and GDFL are data vendors; they are data providers. You can't place orders.
You may check your log reports or DB logs for the delay; most of the people don't know about this issue; they still believe it's a clock drift issue or an AWS server issue, etc.
Hopefully they may change their infrastructure; I am waiting for that moment.
check for more details : delay-in-receiving-ticks , fast-market-data