Data mismatch between timeframes

API Spot/Margin API
1

Sorry for category. I cant read chinese.

Theres data mismatch between aggregated (pandas.resample.aggregate) ohlcv data of timeframes smaller than 1d and original 1d ohlcv data.

vimdiff snippet of mismatching btcusdt data 1d (aggregated from 1h) compared to original 1d data:

178 2018-02-09      7789.9  8826.91 7789.9  8789.85 21642.326726                                                     |  178 2018-02-09      7789.9  8738.0  7789.9  8683.92 20482.910825
179 2018-02-10      8789.85 9065.78 8120.0  8344.35 49244.767863                                                     |  179 2018-02-10      8683.93 9065.78 8120.0  8533.98 49381.512653
180 2018-02-11      8350.03 8500.85 7726.53 8063.88 44002.516841                                                     |  180 2018-02-11      8533.99 8549.0  7726.53 8063.88 45025.187952
2

Can you post the urls or curls of the data you’re referencing?

3

I found out that there is an issue with the candle timestamps:

https://api.binance.com/api/v3/klines?symbol=BTCUSDT&interval=2h&startTime=1518134400000

The timestamps do not match the intervals.

4

Yes, this is due to a historical bug that has since been fixed. We debated modifying the data to align the klines properly but decided to keep the data as it was created and published at the time.

5

Why dont you offer a new endpoint with correct data then? these candles are simply incorrect since the sequence is not in order.

from another perspective I dont see a problem with hotfixing the data

6

The candles are correct for the intervals they represent based on the openTime and the closeTime returned. The issue is that the open/close time is shifted. Reconciling and cleaning up our data is something we’ll look into but we don’t have an ETA at this time.

7

Hello @Ninj0r:
Incorrect ‘L’ in OHLC, triggering my OCO incorrectly. Below are 2 consecutive ouputs of Current BTC/USDT from my python script. my time stamps are GMT+5. You can see that “l” is second output is suddenly dropped to 30998 caused my “STOP_LOSS_LIMIT” to be filled. I can share further logs but this is the main issue. I am testing on ‘SPOT Testnet’. Pls help?.

2021-09-28 10:53:03,531 {‘e’: ‘kline’, ‘E’: 1632808382915, ‘s’: ‘BTCUSDT’, ‘k’: {‘t’: 1632808380000, ‘T’: 1632808439999, ‘s’: ‘BTCUSDT’, ‘i’: ‘1m’, ‘f’: 1494192, ‘L’: 1494205, ‘o’: ‘42440.20000000’, ‘c’: ‘42392.75000000’, ‘h’: ‘42442.85000000’, ‘l’: ‘42263.43000000’, ‘v’: ‘0.25169800’, ‘n’: 14, ‘x’: False, ‘q’: ‘10661.17984461’, ‘V’: ‘0.05892900’, ‘Q’: ‘2499.86802406’, ‘B’: ‘0’}}

2021-09-28 10:53:05,558 {‘e’: ‘kline’, ‘E’: 1632808384940, ‘s’: ‘BTCUSDT’, ‘k’: {‘t’: 1632808380000, ‘T’: 1632808439999, ‘s’: ‘BTCUSDT’, ‘i’: ‘1m’, ‘f’: 1494192, ‘L’: 1494229, ‘o’: ‘42440.20000000’, ‘c’: ‘42392.36000000’, ‘h’: ‘42442.85000000’, ‘l’: ‘30998.00000000’, ‘v’: ‘0.33283600’, ‘n’: 38, ‘x’: False, ‘q’: ‘13669.97959274’, ‘V’: ‘0.09606700’, ‘Q’: ‘4073.95718419’, ‘B’: ‘0’}}