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?
Richard
http://quant-coder.prokopyshen.com/ContactMe

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):  
            return  
        selectionDate  = datetime.date(int(dateparts[0]), int(dateparts[1]), int(dateparts[2]))  
    else:  
        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?

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:

https://www.quantopian.com/posts/details-on-pre-startup-algo-verification-phase-prior-to-debugger-running-prior-to-fundamentals-running

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.