bybit: fetchOHLCV() returns incorrect result about ccxt

[sc0Vu]

Hi @aquanow-xavier,

In bybit, they have the same unified symbol across different market type, eg. both spot and linear for BTCUSDT is BTCUSDT. And the default market type for the query is linear swap (these data was matched with yours n bybit fetchOHLCV BTC/USDT:USDT 1h 1721779200000 500).

The data is correct if you use BTC/USDT.

$ n bybit fetchOHLCV BTC/USDT 1h 1721779200000 500
2024-07-25T05:01:12.193Z
Node.js: v20.11.1
CCXT v4.3.66
bybit.fetchOHLCV (BTC/USDT, 1h, 1721779200000, 500)
2024-07-25T05:01:14.920Z iteration 0 passed in 245 ms

1721779200000 | 65939.31 | 66159.14 | 65759.15 |  65783.9 |  626.229186
1721782800000 |  65783.9 | 66125.47 | 65618.19 | 65671.69 |  819.736092
1721786400000 | 65671.69 | 65934.33 | 65476.25 | 65880.87 |  600.790716
1721790000000 | 65880.87 | 66115.99 | 65783.97 | 66047.12 |  501.795364
1721793600000 | 66047.12 | 66074.33 | 65771.72 | 65857.79 |  446.315277
1721797200000 | 65857.79 |  65918.4 |  65614.8 | 65809.48 |   420.02722
1721800800000 | 65809.48 | 66011.11 | 65754.77 | 65895.59 |  485.379156
1721804400000 | 65895.59 | 66083.84 | 65862.91 | 66079.27 |  372.331138
1721808000000 | 66079.27 | 66460.61 | 66001.22 | 66440.58 |  618.293332
1721811600000 | 66440.58 | 66484.05 | 66297.14 | 66406.77 |  385.618984
1721815200000 | 66406.77 | 66620.07 | 66356.66 | 66507.98 |  484.351583
1721818800000 | 66507.98 | 66571.17 | 66344.21 | 66378.59 |  433.185533
1721822400000 | 66378.59 | 66584.95 | 66175.89 |  66223.3 |  572.004587
1721826000000 |  66223.3 | 66923.19 | 66205.35 | 66350.79 |  973.961744
1721829600000 | 66350.79 | 67112.98 |  66291.6 | 66759.68 | 1011.453701
1721833200000 | 66759.68 | 66821.86 | 66091.75 | 66176.93 | 1095.402846
1721836800000 | 66176.93 | 66495.58 | 65968.75 |  66388.4 | 1209.360486
1721840400000 |  66388.4 |  66713.3 | 66315.15 | 66590.76 |  738.922364
1721844000000 | 66590.76 | 66657.64 | 65714.55 | 65766.65 | 1158.911634
1721847600000 | 65766.65 | 66117.15 | 65563.39 | 65658.45 |  916.245373
1721851200000 | 65658.45 | 66080.64 | 65651.19 | 66053.79 |  539.199154
1721854800000 | 66053.79 | 66073.99 | 65072.02 | 65651.86 |  669.613949
1721858400000 | 65651.86 | 65675.42 | 65250.69 | 65293.35 |  612.728503
1721862000000 | 65293.35 | 65467.54 |    65100 |  65377.2 |  579.171718
1721865600000 |  65377.2 |  65631.1 | 65273.22 | 65508.64 |  638.215076
1721869200000 | 65508.64 | 65511.89 | 64212.32 | 64479.24 | 1846.653205
1721872800000 | 64479.24 | 64484.98 | 63939.42 | 64198.79 | 1234.591464
1721876400000 | 64198.79 | 64292.13 | 63859.17 | 64096.23 | 1007.496893
1721880000000 | 64096.23 | 64288.07 | 63781.21 | 64225.15 |  725.807337
1721883600000 | 64225.15 |  64230.3 | 64186.34 | 64191.92 |    9.065787

Let us know if you have any other issues.

[aquanow-xavier]

Thank you, @sc0Vu. Your explanation is very clear.

It was my mistake to assume the exchange would use a different symbol internally, and there was no need for this assumption in the first place given that I can use the CCXT symbol instead.

I re-read the CCXT Manual page on Symbols and Market Ids. I will only use CCXT symbols going forward to avoid these kinds of issues.