multiple_prices_csv: are the CARRY_CONTRACTs etc contract months or expiries?

[js190]

I can't find any dates (although I am lazy) that do not have 00 at the end, are these then contract dates rather than expiry?
The seemingly rather helpful docstring in contractDate states:

class contractDate(object):
    """
    A single contract date; either in the form YYYYMM or YYYYMMDD
    *or* a list of contract dates

    Typically

    Use cases:
    - normal contract eg 201712 and expiry date like 20171214
    - VIX where contract needs to be defined as 20171214 because of weekly expiries
    - Gas where contract month and expiry date are in different months

    We store the expiry date separately

    Representation is either 20171200 or 20171214 so always yyyymmdd

    Either:

    - we know the expiry date precisely and it's passed when we create the object
    - OR we have to approximate by using the 1st of the month when the object is created
    - OR we can make a better approximation by applying an offset to the approximate date
    """

But the VIX multiple prices all have 00 so is the above comment valid?

How do the expiries and contract dates interact with roll calendar creation, it looks like we just use the contract date and the roll params rather than explicit expires e.g. contractDate.expiry_date

I'm trying an approach of rather than using Arctic to store timeseries I'm using Parquet files on disk with metadata stored somewhere either Mongo or Sqlite

[ChrisAllisonMalta]

I think I remember Rob writing on this on his blog, because there are weekly expiries on the VIX contract, you need to specify the day even if you are trading the monthly expiry

post is here

I'd be interested to see how you implement the alternative data store

[js190]

Yeah that's what the contractDate docstring implies but the multiple_prices_csv files are devoid of any day data in the PRICE_CONTRACT/CARRY_CONTRACT columns - so i'm wondering what the point of the 00 postfix to these columns are?

[robcarver17]

'00' means it's a contract date where we don't know the expiry. For most of pysystemtrade we don't need to know the expiry, so we generally store contract dates without any expiry information (to be pendantic, what you're seeing is the date_str property of the contract month), except in the contract dates database table, and when comparing positions with IB. Perhaps this is confusing but it's quite a faff to change.

[js190]

Thanks that helps, my pedantry threshold is unbounded. I'm going to hit a few bumps as I try and implement this system using the csv files as the seed for my own db outside of Arctic.