Fix bar timestamps for IB

[Endura2024]

Fix wrong ts_init and ts_event value for Day/week/month historical bar data from IBKR #2379

Pull Request

IB only return date for Day/week/month historical bar. For week and month bar, the date represents the end period, not start of period, which is different from other type of bar

Type of change

• Bug fix (non-breaking change which fixes an issue)

How has this change been tested?

wrote a script similar to https://github.com/nautechsystems/nautilus_trader/blob/master/examples/live/interactive_brokers/historical_download.py to inspect output for weekly and day bar:

Before code change:
Nautilus Return:
open high low close volume ts_event
2 476.25 476.36 464.61 468.45 274518743 1704412800000000000
3 467.70 478.60 466.13 475.65 268167290 1705017600000000000
4 474.25 482.75 469.87 482.64 253556992 1705622400000000000
5 483.67 485.99 482.78 485.97 92397875 1705968000000000000

           ts_init               ts_event_dt                ts_init_dt  

1 1704412800000000000 2023-12-28 19:00:00-05:00 2024-01-04 19:00:00-05:00
2 1705017600000000000 2024-01-04 19:00:00-05:00 2024-01-11 19:00:00-05:00
3 1705622400000000000 2024-01-11 19:00:00-05:00 2024-01-18 19:00:00-05:00
4 1706227200000000000 2024-01-18 19:00:00-05:00 2024-01-25 19:00:00-05:00
5 1706572800000000000 2024-01-22 19:00:00-05:00 2024-01-29 19:00:00-05:00

Daily: (for date range 1/1-1/3)
open high low close volume ts_event
1 476.25 476.36 470.49 472.50 78816098 1704153600000000000
2 472.07 472.53 468.17 469.35 72887442 1704240000000000000

           ts_init               ts_event_dt                ts_init_dt  

1 1704240000000000000 2024-01-02 00:00:00+00:00 2024-01-03 00:00:00+00:00
2 1704326400000000000 2024-01-03 00:00:00+00:00 2024-01-04 00:00:00+00:00

After:

Weekly
open high low close volume ts_event
3 476.25 476.36 464.61 468.45 274518743 1704067200000000000
4 467.70 478.60 466.13 475.65 268167290 1704672000000000000
5 474.25 482.75 469.87 482.64 253556992 1705276800000000000
6 483.67 485.99 482.78 485.97 92397875 1705881600000000000

           ts_init               ts_event_dt                ts_init_dt  

3 1704412800000000000 2024-01-01 00:00:00+00:00 2024-01-05 00:00:00+00:00
4 1705017600000000000 2024-01-08 00:00:00+00:00 2024-01-12 00:00:00+00:00
5 1705622400000000000 2024-01-15 00:00:00+00:00 2024-01-19 00:00:00+00:00
6 1705968000000000000 2024-01-22 00:00:00+00:00 2024-01-23 00:00:00+00:00

Daily:
open high low close volume ts_event
1 476.25 476.36 470.49 472.50 78816098 1704153600000000000
2 472.07 472.53 468.17 469.35 72887442 1704240000000000000

           ts_init               ts_event_dt  \

1 1704239999999999999 2024-01-02 00:00:00+00:00
2 1704326399999999999 2024-01-03 00:00:00+00:00

                       ts_init_dt  

1 2024-01-02 23:59:59.999999999+00:00
2 2024-01-03 23:59:59.999999999+00:00

[CLAassistant]

All committers have signed the CLA.

[cjdsellers]

Hi @Endura2024

Many thanks for the contribution, and thanks for providing the test results.

As a separate follow up, I think it would make the code clearer if we used the enum itself - rather than the int values.
Understood that you were just following the established pattern though.

[faysou]

I'm ok with the logic. One comment after the merge is that aggregation type enums should be used instead of constants like 14, 15, 16 which are hard to understand if someone doesn't know the code.