Bit of an odd issue, but I was doing some data QA in preparation for year close… and I found some 400+ “missing trades” that my deployment had not picked up.
Upon closer inspection, it looks like the API returns 4 different types of datetime format for this year (Happens at various points, even as recently as this week), for the trade_time column:
The timestamp format you are seeing from the Advanced Trade API can indeed include up to nanosecond precision as indicated in your examples, although this level of precision is not always included. The variation in precision can be related to several factors such as the specific infrastructure the timestamp originated from and the particular event or action the timestamp is associated with.
It is expected behavior that the precision may vary. There is no specific logic tied to nanoseconds appearance relating to multiple fills in the same millisecond. The precision of the timestamps does not correlate to the occurrence of such events. If you are experiencing missing trades, it is unlikely that the variation in timestamp precision is the cause. Instead, issues such as network latencies, system outages, or API rate limits may be more likely causes.
However, if you still believe there is an issue with the trades, it is recommended that you submit the order_ids for those trades to Coinbase support for further investigation. When dealing with these timestamps in your code, aim to use parsing methods that can handle varying levels of precision for ISO 8601 timestamps, as most modern programming languages and their standard libraries should be able to.
They were missing from my own deployment inserting them as I was using datetime.strptime and datetime only supports micro seconds, but not nanoseconds. PEP 410 – Use decimal.Decimal type for timestamps | peps.python.org , so my pod was failing to parse them and moving on… and it was rare enough (< 0.1%) that I had missed it.
It is expected behavior that the precision may vary.