Potentially inconsistent execution fill times

[odarr]

Exceptional project @erdewit, have learnt so much from your work here so thank you for sharing it with us all.

This issue is really just a heads up to users of the library of a slightly tricky to catch inconsistency but additionally might be room for a small improvement.

Execution fill times are created in line 405 in execDetails method in decoder.py

ib_insync/ib_insync/decoder.py

Line 405 in 7ecfccc

ex.time = parseIBDatetime(time).astimezone(timezone.utc)

Here the IB datetime string representing the execution fill time is parsed into a naive (timezone-unaware) python datetime object. When the .astimezone method is called on a naive datetime, the machine's local timezone is assumed as the timezone to adjust from, see

https://github.com/python/cpython/blob/582aaf19e8b94a70c1f96792197770d604ba0fdf/Lib/datetime.py#L1867.

This worked fine for me until I travelled from the UK (where I was when I initially installed TWS) to Europe. I didn't change the timezone in the login dialog box and so IB datetime strings, which were still localized to Europe/London timezone, were being parsed and adjusted to UTC assuming my machine's local timezone, which was Europe/Berlin, and this resulted in execution object fill times that did not match the times in the TWS trade log.

TWS login dialog showing timezone dropdown

Heads Up

Of course this issue is totally avoided if you just manually set the timezone to the machine local timezone wherever you happen to be when you login to TWS. However, for users who don't always run their TWS session with the timezone matching the machine local timezone, because, for instance they like to keep their TWS timezone local to the markets they trade even when they travel, they are likely recording incorrect execution fill times.

Improvement?

In terms of a possible improvement, ideally IB-insync would be able to discern what timezone is being used in the running TWS session and then localize to that before adjusting to UTC. As far as I'm aware there is nothing in the TWS API that would provide us with this information so my workaround for now has been to pick a TWS session timezone and stick with it (e.g. I use Europe/London) - this is easy (and also kind of the source of the issue) because once you set it, it does not change, even if your machine happens to be in a different timezone. I then made the following changes to the Decoder.execDetails method

# ex.time = parseIBDatetime(time).astimezone(timezone.utc)
ex.time = (
    pytz.timezone("Europe/London")
    .localize(parseIBDatetime(time))
    .astimezone(pytz.UTC)
)

So I localize to the timezone I have set the TWS session to be first and so there is always consistency of timezone at the boundary between incoming IB execution message and creation of python execution object.

Apologies for the rather lengthy post which was really just to make sure users were aware of this potential hazard. I suspect there isn't much to be done about this so @erdewit please feel free to close at will.

[erdewit]

A IB.TimezoneTWS field has been added, so that patching the decoder is no longer necessary. For the above case one can use

IB.TimezoneTWS = pytz.timezone("Europe/London")