Back to Community
Anomalous behavior in initialize() regarding datetimes

Q Tribe, I'm a bit confused here (not a surprise). I can stop the below code in the debugger and get things to respond with the correct values. But when I try and run it in a backtest and I get this error:

Runtime exception: AttributeError: 'NoneType' object has no attribute 'year'
(enter whatever you're trying to pull off of the start_date)

Each of these fail

def initialize(context):  
    startDate = # fails  
    startDate = context.portfolio.start_date  
    startDate = datetime.datetime(startDate.year, startDate.month, # fails

Yet if I stop and interrogate the various incantations of startDate:

date:, 10, 31)

Timestamp: 2006-10-31 00:00:00+00:00

MySecurityList[0]["Date"] == startDate  

MySecurityList[0]["Date"] ==  

Where MySecurityList looks like this:

MySecurityList = [
{"Date",10,31), "Stuff here": ...

Any ideas, clues or whiskey to offer?

9 responses

Hello Market Tech
Cant't explain it, but I found it interesting that creating a pandas.tslib.timestamp object (which is what context.portfolio.start_date is reported to be) in initialize appears to work as expected. Might be related to the code scanner/builder Q uses?

Clone Algorithm
Backtest from to with initial capital
Total Returns
Max Drawdown
Benchmark Returns
Returns 1 Month 3 Month 6 Month 12 Month
Alpha 1 Month 3 Month 6 Month 12 Month
Beta 1 Month 3 Month 6 Month 12 Month
Sharpe 1 Month 3 Month 6 Month 12 Month
Sortino 1 Month 3 Month 6 Month 12 Month
Volatility 1 Month 3 Month 6 Month 12 Month
Max Drawdown 1 Month 3 Month 6 Month 12 Month
# Backtest ID: 556af7c5e4bb5c107c7f2ee8
There was a runtime error.

I have encountered this as well and now I unfortunately convert to a string and use slicing to get the year month etc. I assumed I did something stupid and therefor I didnt report it and worked around it....

Thanks Richard and Peter.

This is just sad. I finally got something to work. For whatever reason, the pre-processing done before initialize() is called does some poor variable checking. I had to resort to this convolution of string parsing. Just plain ugly.

def DoCustomInitialize(context, loadDate, isFromInitialize):  
    if (isFromInitialize):  
        testDate  = str(context.portfolio.start_date).split(" ")[0]  
        dateparts = testDate.split("-")  
        if (len(dateparts) < 3):  
        selectionDate  =[0]), int(dateparts[1]), int(dateparts[2]))  
        selectionDate = loadDate  

It's clear that get_datetime() should work inside initalize() and return the start_date of the test.

Quantopian: please register this as a bug.

AttributeError: 'NoneType' object has no attribute 'tzinfo'
There was a runtime error on line 5.

I agree, this looks frustrating.

Just to be clear - your ultimate goal here is to know the test startdate from within your algorithm?


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.

Dan, yes. We require a bit of preprocessing in order to arrive at a known state based on the start date (of either the back test or the real time start). The pandas timestamp would be OK if only it would make it through the precompile. What's odd is that a None type is sent through the code as some sort of proof prior to start. This then throws errors that won't let the strat even kick off. But the actual data that enters initialize() is correct and usable, IF you can get into it.

Another way to round up the start date:

def initialize(context):  
    print get_environment('start').date()  
1970-01-01 PRINT 2013-05-01 13:31:00+00:00  

Other info, using *

def initialize(context):  
    print str(get_environment('*'))  

I meddled with this a bit for readability here:

1970-01-01 PRINT {  
    'start'         : Timestamp('2013-05-01 13:31:00+0000', tz='UTC')  
    'end'           : Timestamp('2015-04-30 20:00:00+0000', tz='UTC'),  
    'data_frequency': 'daily',  
    'arena'         : 'backtest',  
    'platform'      : 'quantopian',  
    'capital_base'  : 100000.0,  

@Gary, Thanks for this. What may have been my issue all along was that I was using an invalid start_date. 1/1/2015 is obviously not a valid market date. And your test showed that the environment start was actually on the 2nd of January.

I then went on and set the start date of the test to Saturday 1/3/2015. Environment produced the start of 1/5/2015 but start_date still produced the 3rd. Your solution coupled with the fact that handle_data won't get called anyway until the next open market date solves my problem. Thanks.

(Dan, start_date, may have been causing problems due to the fact that I was using a non-market date. Nope. Just tested. Only Gary's solution works. Or my ugly date string parsing.)

I often see situations where the pre-start "validation" throws errors that ought to be impossible in an actual algo run. I tried to ask for help here:

Nothing really came out of it. I suspect that the IDE or something is trying to produce "compile" errors, which is naturally exceedingly difficult to do properly with Python, but it causes more problems than it solves IMO.