Quantopian's community platform is shutting down. Please read this post for more information and download your code.
Back to Community
Error in log files?

In a previous thread (https://quantopian.com/posts/template-limit-leverage-in-your-algos#51e82f6153ddf0d6a2000066) a fellow Quantopian-user noticed a seeming postdictive error when reviewing his log file. I decided to dig a little deeping on that possible problem and quickly generated the following code:

def initialize(context):  
    pass

# Will be called on every trade event for the securities you specify.  
def handle_data(context, data):  
    # Implement your algorithm logic here.

    # data[sid(X)] holds the trade event data for that security.  
    # data.portfolio holds the current portfolio state.

    # Place orders with the order(SID, amount) method.

    # TODO: implement your own logic here.  
    d=get_datetime()  
    log.info(d)  
    order(sid(24), 50)  

which stores the date in d and then prints it to the log file. I ran this on daily data and here is the output:

2008-01-03handle_data:17INFO2008-01-04 00:00:00+00:00
2008-01-06handle_data:17INFO2008-01-07 00:00:00+00:00
2008-01-07handle_data:17INFO2008-01-08 00:00:00+00:00
2008-01-08handle_data:17INFO2008-01-09 00:00:00+00:00
2008-01-09handle_data:17INFO2008-01-10 00:00:00+00:00
2008-01-10handle_data:17INFO2008-01-11 00:00:00+00:00

So when get_datetime() returns 2008-01-04 , the log file prints the comment leading with 2008-01-03. Is this a bug or intentional?

7 responses

Bug! We haven't tracked it down yet, but it's very high on my list (for obvious reasons).

The "minutely" mode appears to be logging correctly.

Disclaimer

The material on this website is provided for informational purposes only and does not constitute an offer to sell, a solicitation to buy, or a recommendation or endorsement for any security or strategy, nor does it constitute an offer to provide investment advisory services by Quantopian. In addition, the material offers no opinion with respect to the suitability of any security or specific investment. No information contained herein should be regarded as a suggestion to engage in or refrain from any investment-related course of action as none of Quantopian nor any of its affiliates is undertaking to provide investment advice, act as an adviser to any plan or entity subject to the Employee Retirement Income Security Act of 1974, as amended, individual retirement account or individual retirement annuity, or give advice in a fiduciary capacity with respect to the materials presented herein. If you are an individual retirement or other investor, contact your financial advisor or other fiduciary unrelated to Quantopian about whether any given investment idea, strategy, product or service described herein may be appropriate for your circumstances. All investments involve risk, including loss of principal. Quantopian makes no guarantees as to the accuracy or completeness of the views expressed in the website. The views are subject to change, and may have become unreliable for various reasons, including changes in market conditions or economic circumstances.

Interesting - thanks Dan, Just wanted to make sure I was reading this correctly.

This is now fixed. The log time stamp was suffering from a UTC/EDT conversion problem, and was being cast back to "yesterday" in daily mode. The actual backtest was OK.

Thanks Dan.

Glad people are digging deep! When fixes like this are implemented in Quantopian.com, are they also rolled into zipline on github (assuming the update, or any others are affect the zipline package)?

[for example was this the "BUG: Trading calendar dates should always be midnight UTC" fix today?]

Thanks,
Ken

Ken, it actually works the other way around. When we have a bug in Zipline, we fix it there, and then Quantopian starts using that new version of Zipline. However we do get the right result, which is any change is in both places.

In this particular case, the bug was in the Quantopian part of the code - Zipline was fine. The backtester was emitting a date that was midnight UTC, and the UI was casting that in an unexpected way, and the result was it looked like yesterday.

The bug in Zipline you mentioned (#208 is different than the one here. #208 is about the date formats when we're talking about the trading calendar, not logging. Here's how the process works: When #208 is fixed, that change will be included in Zipline. Some time after that (sometimes hours, sometimes days) the Quantopian website is updated to include the latest version of Zipline.

My duh - that certainly makes more sense. Mod in the github repo, validate and then fold into production version Quantopian.

Thanks for the info!

Best,
Ken