The price and volume data is always from the previous minute. This ensures there is no look ahead bias. Data from 00:00:00-00:01:00 has a timestamp of 00:01:00. A finer detail is that the interval is 'right closed' and 'right labeled' (using Pandas resample terminology). In other words, 00:00:00 < data <= 00:01:00 and would be labeled 00:01:00. (see interval definition at https://en.wikipedia.org/wiki/Interval_(mathematics))

As a further example. Since US equity markets are open from 9:30am - 4:00pm one will see timestamps from 09:31 - 16:00.

Hope that helps.

Thanks a lot Dan!

I have a follow up question.

Applying this logic to daily candles means that a candle labeled "2017-01-04 00:00" will hold the information of this period: 2017-01-03 00:00 => 2017-01-04 00:00.

When running a simple daily algorithm and looking at the information returned for the current and history API functions, I get the following:

data.current_dt : 2017-01-04 16:00:00+00:00

data.current(symbol('AAPL'), ['close']) : 116.02

data.history(symbol('AAPL'), ['close'], 2, '1d') :
2017-01-03 00:00:00+00:00 116.15
2017-01-04 00:00:00+00:00 116.02

So my question is why the current price is equal to the price from the 2017-01-03 00:00:00 => 2017-01-04 00:00:00 period if the current simulation time is the end of the trading day of 2017-01-04.

Thanks

'I believe the issue is a misunderstanding of what the 'data.history' method, with a '1d' frequency, returns. It always returns the current minute data plus previous end-of-day data. Look at the docs (especially the example) under https://www.quantopian.com/help#ide-history . Here is an excerpt.

• data.history(context.assets, "price", 1, "1d") returns the current price.
  
• data.history(context.assets, "volume", 1, "1d") returns the volume since the current day's open, even if it is partial.
  
• data.history(context.assets, "price", 2, "1d") returns yesterday's close price and the current price.
  
• data.history(context.assets, "price", 6, "1d") returns the prices for the previous 5 days and the current price.

This behavior may not be entirely intuitive but it is convenient at times. Just realize that the last price returned is the last known price for the current trading day and NOT the final price. There is still no lookahead bias. This approach can save an extra call to 'data.current'.

Hope that helps answer your question.

Thanks for the clarification.

The original question was aiming to the value of the simulation clock (represented in the data.current_dt).
If each tick represents the end of the period (in daily mode, the end of the trading day - 16:00) then the current price (retrieving using data.currrent or data.history) should not be the final price of this period, and not the previous one?
Using the example above, in daily mode, if the simulation clock is 2017-01-04 16:00:00, shouldn't the current price be the final price of 2017-01-04 (and not the final price of 2017-01-03)?

Thanks !

Maybe some clarification is needed.

What do you mean by "Using the example above, in daily mode".? Are you saying that you are running zipline offline and running it in 'daily' mode (note that the Quantopian implementation only runs in minute mode). Or, are you saying that you are executing the command with a frequency of '1d' as shown below

    price_history = data.history(SPY, 'price', LOOKBACK, '1d')  
    price_current = data.current(SPY, 'price')

If you mean the latter, then it's confusing because 'data.current' doesn't have a frequency parameter.

Ohh, you are completely correct, sorry for the confusion.
I was trying to understand the simulation clock and the timestamp labels used by the Quantopian engine, both by using the platform and the zipline stand alone SW.

Sorry for the confusion, the example I've attached was relevant to zipline daily mode.
Trying to rephrase the question: if the simulation tick is in the end of the period (minute or daily) should the current information be relevant for this period and not the one before?

Thanks!