Backtrader中文笔记之DateTime Management

原文地址:https://www.backtrader.com/docu/timemgmt/

DateTime Management

日期时间管理

Up until release 1.5.0, backtrader used a direct approach to time management in that whatever datetime was calculated by data sources was simply used at face value.

在1.5.0版本之前，backtrader使用直接的时间管理方法，无论数据源计算的日期时间是什么，都只是按面值使用。

And the same for any user input like in the case of the parameter fromdate (or sessionstart) which can be given to any data source

对于任何用户输入都是一样的，比如参数fromdate（或sessionstart）可以给任何数据源

The approach was fine given the direct control over frozen data sources for backtesting. It was easy to assume that the input datetimes had already been taken care of before they entered the system.

考虑到直接控制用于回溯测试的冻结数据源，该方法很好。很容易假设输入的日期时间在进入系统之前就已经处理好了。

But with 1.5.0, live data sources are supported and this forces to take into account datetime management. Such management would not be needed if the following were always true:

但在1.5.0中，支持实时数据源，这就迫使我们考虑日期时间管理。如果以下情况始终正确，则无需进行此类管理：

• A trader in New York trades the ES-Mini. The time zone for both in US/Eastern (or one of the aliases)

• 纽约的一名交易员交易ES Mini。美国/东部的时区（或别名之一）

• A trader in Berlin trades the DAX future. In this case for both the CET (or Europe/Berling) timezone applies

• 柏林的一名交易员交易DAX期货。在这种情况下，CET（或欧洲/柏林）时区都适用

The direct input-output datetime approach from above would work, becase the trader, in Berlin for example, could always do something like this:

上面的直接输入-输出日期时间方法是可行的，因为例如柏林的交易员总是可以这样做：

class Strategy(bt.Strategy):

    def next(self):

        # The DAX future opens at 08:00 CET
        if self.data.datetime.time() < datetime.time(8, 30):
            # don't operate until the market has been running 30 minutes
            return  #

 The problem with the direct approach surfaces when the same trader in Berlin decides to trade the ES-Mini. 

当柏林的同一个交易员决定交易纽交所的ES-Mini时，直接交易的问题就浮出水面。

Because the change to from DST happens at different point in time in the year and this causes the time difference to be out of sync a couple of weeks during the year. The following wouldn’t always work:

因为在一年中的不同时间点将发生DST的更改，这会导致时间差在一年中的数周内不同步。以下方法并不总是有效：

class Strategy(bt.Strategy):

    def next(self):

        # The SPX opens at 09:30 US/Eastern all year long
        # This is most of the year 15:30 CET
        # But it is sometimes 16:30 CET or 14:30 CET if a DST switch on-off
        # has happened in the USA and not in Europe

        # That's why the code below is unreliable

        if self.data.datetime.time() < datetime.time(16, 0):
            # don't operate until the market has been running 30 minutes
            return  #

 

Operation with timezones

时区操作

To solve the aforementioned situations and still remain compatible with the direct input-output time approach, backtrader offers the end user the following

为了解决上述情况，并且仍然与直接输入输出时间方法兼容，backtrader为最终用户提供了以下内容

Datetime Input

日期时间输入

• As a default the platform will not touch the datetime provided by a data source

• 默认情况下，平台不会接触数据源提供的日期时间

•  

  • The end-user can override this input by:

  • 终端用户可以通过以下方式覆盖此输入：

  • Providing a tzinput parameter to the data source. This must be an object compatible with the datetime.tzinfo interface. Most likely the user will provide a pytz.timezone instance

  With this decision the time used internally by backtrader is considered to be in UTC-like format, ie:

• 向数据源提供tzinput参数。此对象必须是datetime.tzinfo接口。用户很可能会提供pytz.timezone实例，有了这个决定，backtrader内部使用的时间被认为是类似于UTC的格式，即：

•  

  • If the data source has already stored it in UTC format

  • 如果数据源已将其存储为UTC格式

  • After a conversion through tzinput

  • 通过tzinput转换后

  • It’s not really UTC but it’s the reference for the user, hence UTC-like

  • 它不是真正的UTC，但它是用户的参考，因此类似UTC

Datetime output

• If the data feed can automatically determine the timezone for the output, this will be the default

• 如果数据源可以自动确定输出的时区，这将是默认值

  This makes sense in the case of live-feeds and especially in use cases like the one in which a trader in Berlin (CET timezone), trades products with US/Eastern timezone.

• 这在实时数据的的情况下是有意义的，比如一个是在柏林（CET时区）的交易员与US/Eastern交易产品的用例中。

  Because the trader gets always the right time and in the example above the opening time remains constant at 09:30 US/Eastern, rather than 15:30 CET most of the year, but sometimes 16:30 CET and sometimes 14:30 CET.

• 因为交易者总是得到正确的时间，在上面的例子中，开盘时间保持不变，在美国东部时间09:30，而不是一年中大部分时间的15:30，但有时是欧洲中部时间16:30，有时是欧洲中部时间14:30。

• If it cannot be determined, then the output will be whatever was determined during input (the UTC-like) time

• 如果在输入期间无法确定UTC，则可以确定它

• The end user can override and determine the actual timezone for the output

• 终用户可以覆盖并确定输出的实际时区

  • Providing a tz parameter to the data source. This must be an object compatible with the datetime.tzinfo interface. Most likely the user will provide a pytz.timezone instance
  • 向数据源提供tz参数。此对象符合datetime.tzinfo接口。大多数用户很可能会提供pytz.时区实例

 

Note

Input fromt the user like for example the parameters fromdate or sessionstart are expected to be in sync with the actual tz, be it automatically calculated by the data source, supplied by the user or left as default (None, which means direct input-output of datetime)

用户喜欢的输入例如fromdate或sessionstart的参数应该与实际的tz同步，无论它是由数据源自动计算的，还是由用户提供的，或者保留为默认值（None，表示日期时间的直接输入输出）

 

With all that in mind let’s recall the Berlin trader, trading in US/Eastern:

 

考虑到这些，让我们回顾一下柏林交易员，在US/Eastern进行交易：

import pytz

import bt

data = bt.feeds.MyFeed('ES-Mini', tz=pytz.timezone('US/Eastern'))

class Strategy(bt.Strategy):

    def next(self):

        # This will work all year round.
        # The data source will return in the frame of the 'US/Eastern' time
        # zone and the user is quoting '10:00' as reference time
        # Because in the 'US/Eastern' timezone the SPX index always starts
        # trading at 09:30, this will always work

        if self.data.datetime.time() < datetime.time(10, 0):
            # don't operate until the market has been running 30 minutes
            return  #

 In the case of a data source which can automatically determine the output timezone:

对于能够自动确定输出时区的数据源：

import bt

data = bt.feeds.MyFeedAutoTZ('ES-Mini')

class Strategy(bt.Strategy):

    def next(self):

        # This will work all year round.
        # The data source will return in the frame of the 'US/Eastern' time
        # zone and the user is quoting '10:00' as reference time
        # Because in the 'US/Eastern' timezone the SPX index always starts
        # trading at 09:30, this will always work

        if self.data.datetime.time() < datetime.time(10, 0):
            # don't operate until the market has been running 30 minutes
            return  #

 

Even less work than above.

比上面的工作还要少。

Obviously MyFeed and MyFeedAuto in the example above are just dummy names.

显然，上面示例中的MyFeed和MyFeedAuto只是虚拟名称。

Note

At the time of writing the only data source included in the distribution which can automatically determine the timezone is the one connecting to Interactive Brokers

在编写本文时，分发中唯一可以自动确定时区的数据源是连接到交互式代理的数据源