bmoscon
commented
2 years ago this has been asked a few times, though it may be hard to search for. The timestamp from the exchange is just that - they provide it and there is no real way to verify that they are or are not putting the correct timestamp on anything. The receipt timestamp is the time when the message is processed off the websocket internal queue by cryptofeed. This one is based off your system clock, which may or may not be correct. You can ensure you are syncing your machine with NTP or something similar to eliminate clock drift. If you are 100% sure that the clock on your machine is correct, seems like the error would be on the exchange's side (though its possible it could be a bug in the code, you'd have to look into that for the specific exchange because some exchanges provide timestamps some, provide datetimes, etc). If you provide the exchange, I can take a look
anovv
What could be the reason for timestamp for all channels to be larger than receipt_timestamp?
For me it mostly happens during local development (running via docker on my local machine). My idea was that it could be something with local clock synchronisation, but the difference is usually very small, e.g milliseconds to seconds (magnitude of network latency), but with negative sign.
My understanding is that timestamp is the exchange reported time and receipt_timestamp is cryptofeed local time.
Is it correct? What could be a reason for this behaviour?
Thanks!