3. Trading Calendar possible implementation problems?
For code/output blocks: Use ``` (aka backtick or grave accent) in a single line before and after the block. See: http://commonmark.org/help/

Trading Calendar possible implementation problems?


  • I am trying to implement my own class derived from TradingCalenderBase and I am trying for some time to understand the existing implementation TradingCalendar. I have problems implementing the function schedule (and I do not fully understand the implementation in TradingCalendar either).

    So either its my bad or maybe there even is a bug in the current implementation. The first is more probable :)
    I will just explain what I see and what I do not understand, please feel free to correct me where I am wrong. I do not say my findings are facts.

    The current implementation in TradingCalendar is this:

        def schedule(self, day, tz=None):
        '''
        Returns the opening and closing times for the given ``day``. If the
        method is called, the assumption is that ``day`` is an actual trading
        day

        The return value is a tuple with 2 components: opentime, closetime
        '''
        while True:
            dt = day.date()
            try:
                i = self._earlydays.index(dt)
                o, c = self.p.earlydays[i][1:]
            except ValueError:  # not found
                o, c = self.p.open, self.p.close

            closing = datetime.combine(dt, c)
            if tz is not None:
                closing = tz.localize(closing).astimezone(UTC)
                closing = closing.replace(tzinfo=None)

            if day > closing:  # current time over eos
                day += ONEDAY
                continue

            opening = datetime.combine(dt, o)
            if tz is not None:
                opening = tz.localize(opening).astimezone(UTC)
                opening = opening.replace(tzinfo=None)

            return opening, closing

    This is what I am struggling with the most:

    while True:
...
    if day > closing:  # current time over eos
        day += ONEDAY
        continue

    I am not totally sure what this code means to do. But when analyzing where schedule is used (in feed._getnexteos) I guess the whole point of schedule is actually not to return opening and closing time for the date specified by date but to return the session that ends next. This would be in contradiction to the function header saying Returns the opening and closing times for the given day. Is this correct so far?

    When thinking about that, some possible problems came to mind:

    1. Regarding that while-loop: let's say we have regular trading hours Mon to Fri from 09:00 to 18:00. If the function gets called with day being a random trading day date with its time being 18:05 then I suspect it will run into an endless loop cause day will always be greater than closing. ONEDAY will be added again and again but the actual time will never chance so it will always be greater than the current date's closing time. Is this a bug or did I misinterpret? Maybe there are assumptions this function makes to avoid this scenario to ever happen?
      Suggestion: Do the compare day > closing always with the original datetime value passed to the function (and not with the variable day which got increment by ONEDAY)

    2. I think there is a problem for trading hours that start before UTC midnight 00:00 and end after. Let's say opening is 22:00 UTC and closing 06:00 UTC.
      Let's take New Zealand exchange which opens at 22:00 UTC and closes at 05:00 UTC (+12h UTC offset). So when calling schedule with day being e.g. 2005-05-23 04:00 UTC we are actually in NZSX's trading hours (2005-05-22 22:00 UTC to 2005-05-23 05:00 UTC) from date 2005-05-22 (22th !) which should be the expected return value. But the function would start search at the provided date 2005-05-23 and therefore miss the 22th and return then opening and closing times for the 23th which are 2005-05-23 22:00 UTC to 2005-05-24 22:00 UTC. This would be wrong I suspsect.
      Suggestion: Do not start searching exactly from the provided date in day but from the day before (Subtract ONEDAY before starting the search).

    3. If this is true day > closing then ONEDAY will be added and then searched again for the next day. But there is no check if the next day is a trading day at all. I think this is missing and can lead to returning trading hours for a non-trading day.
      Suggestion: Instead of adding ONEDAY, call _nextday to jump the actual next trading day.

    0
    B
     1 Reply

  • Could you maybe comment on my assumption that the interface of the function schedule is to return the opening and closing time of the session that ends next (instead of the opening/closing for the provided day)?
    It's the important point for me. I can hopefully deal with the rest alone.

    0
  • B
    administrators

    @vbs said in Trading Calendar possible implementation problems?:

    while True:
    ...
    if day > closing: # current time over eos
    day += ONEDAY
    continue

    What this code does: if the current day given as param is not a trading day, go for the next. A day has no time (which can be equaled to 00:00:00, but closing contains a time component which should be greater than 00:00:00)

    If you pass a Monday and it is an active trading day, the loop won't go to the next day. If you pass a Sunday and it isn't a trading day (which is most likely the case), the loop will go to the next day, i.e.: Monday

    @vbs said in Trading Calendar possible implementation problems?:

    Could you maybe comment on my assumption that the interface of the function schedule is to return the opening and closing time of the session that ends next (instead of the opening/closing for the provided day)?

    As explained above. It will return the closing of the given day if its a trading day and move to the next if it isn't.

    @vbs said in Trading Calendar possible implementation problems?:

    1. I think there is a problem for trading hours that start before UTC midnight ...

    2005-05-23 is not greater than 2005-05-23 05:00 UTC (which when comparing carries no timezone payload and is simply 2005-05-23 05:00) so day > closing will not happen

    @vbs said in Trading Calendar possible implementation problems?:

    1. If this is true day > closing then ONEDAY will be added and then searched again for the next day. But there is no check if the next day is a trading day at all. I think this is missing and can lead to returning trading hours for a non-trading day.

    If day has been found in the database, it won't go over. This is for the case in which the day is not found and the default times from the parameters are taken. In that case there can be no check to see if the day is a trading day or not, because it wasn't found and one works blindly.

    0