Conservative trading hours & timezone

[tgibson11]

@robcarver17 @rorymac @meldinman

I've got a change queued up to apply the gmt_offset from private config to conservative trading hours. You can see the code

After coding this up, it occurred to me that we could instead move the conservative trading hours dictionaries to private config.

Pros (of using config):

• easier to maintain, not having to mentally translate between local time & GMT if a user wants to adjust the conservative hours
• simpler code

Cons:

• more stuff to maintain in private config
• existing code doesn't handle cases where trading hours span midnight in user's timezone (although we could add that part from my proposed changes)

Anyone have thoughts?

[meldinman]

Thats kind of what I did, I just modified the dict in get_conservative_trading_time_for_time_zone and then set my GMT_offset = -5
For me on eastern time I modified my Dict to:

def get_conservative_trading_time_for_time_zone(time_zone_id: str) -> openingTimesAnyDay:

    start_times = {
        ## US
        "CST (Central Standard Time)": 10,
        "US/Central": 10,
        "CST": 10,

        "EST (Eastern Standard Time)": 9,
        "US/Eastern": 9,
        "EST": 9,

        ## UK
        "GB-Eire": 4,
        "": 9,

        ## Middle European
        "MET (Middle Europe Time)": 3,
        "MET": 3,

        ## Asia
        "JST (Japan Standard Time)": 0,
        "JST": 0,
        "Japan": 0,
        "Hongkong": 0,

    }

    end_times = {
        ## US
        "CST (Central Standard Time)": 16,
        "US/Central": 16,
        "CST": 16,

        "EST (Eastern Standard Time)": 15,
        "US/Eastern": 15,
        "EST": 15,

        ## UK
        "GB-Eire": 11,
        "": 15,

        ## Middle European
        "MET (Middle Europe Time)": 10,
        "MET": 10,

        ## Asia
        "JST (Japan Standard Time)": 6,
        "JST": 6,
        "Japan": 6,
        "Hongkong": 6,
    }

    conservative_start_time = datetime.time(start_times[time_zone_id])
    conservative_end_time = datetime.time(end_times[time_zone_id])

    return openingTimesAnyDay(conservative_start_time,
                              conservative_end_time)

It's not ideal but was the quickest solution for me. Your proposed solution is probably the most user friendly for everyone going forward.

[oldlore]

I basically copied meldinman's approach with the addition of using the one_off_adjustments function in the ib_trading_hours.py to "force" some of the instruments to trade in a smaller time window. Very janky but it was the best I could do on short notice.

I'm not very good with Python but I was looking at a library called DateTimeRange: (https://pypi.org/project/DateTimeRange/)
One of it's methods let's you take 2 "datetimeranges" and get the overlap between them. You could get the trading times from IB and then run the intersection between the ideal market hours and the IB hours and use that. Just a thought.

[robcarver17]

This thread. And #687

When people are tying themselves in knots trying to get the current approach to work, it's usually a sign that the approach is flawed.

I'm wondering whether this is a problem that is too complicated to solve with code that trys to dynamically evaluate the correct trading hours for an instrument.

I'm thinking the following - create a table for trading hours.

This could be stored in .csv to allow manual hacking.

We assume that all weeks are the same, so there is basically a series of records for each day of the week.

We allow two trading sessions per day, this also allows weird start/end times to work eg session one 1900-0000, session two 0000 - 0500 for example.

So each instrument will have 7*2 = 14 columns of data trading hours.

There could be utility scripts that read the current trading hours from IB and create the initial set of records using some conservative settings, update the trading hours based on what IB has for the next week, push all trading hours backwards and forwards by N hours, and so on.

We'd still get trading hours from IB and the trading hours we would use are the intersection between the stored hours and the IB hours. This means we can pick up closed markets, half day holidays, and times when there has been a DST change that we haven't reflected in our own data.

Think of all the flexibility - you could trade for just one hour a day if you wished. Or 24 hours in principal (which means you would just pick up the IB hours).

Thoughts?

(I note in passing that this is the approach we used at AHL, and I used in my 'first system' before pysystemtrade)

[tgibson11]

This sounds great to me. I was trying to work within the existing approach and keep changes to a relative minimum. But it does seem like complete redesign might be in order.

[robcarver17]

Created an issue

[robcarver17]

Hopefully there is now a solution