Period sequence

[HalleyInteractive]

Currently we're basing all periods on start date + period length * period number. I think this can get really buggy. This might be a problem if a time zone changes or the length of a period and you want to get the previous already planned period. In this case the start/end dates don't match the current period anymore.

Maybe a solution is to add a period number/sequence number in the period schema. In that case when you change the period length or time zone two periods might not completely match each other, but you'll be able to find them.

[GriffinSauce]

Time zones should not affect dates. This is only because we are using the Date object that is affected. I propose going to DDMMYYYY notation everywhere. It is clearer and less data.

Indexing is an idea. But when period lengths can change it creates all kinds of other issues: we'll need to move dates in periods around (to preserve availability), also: are dates still planned? What if you planned two weeks and go to a two-week period, do you keep the planned dates or erase one?

The solution I see for the issues:

• Use DDMMYYYY instead of date objects, this removes all timezone issues
• When period length is changed, move all dates to appropriate periods, erase all planned dates

We can add indexing and a 'next' and 'previous' API call to make it a bit more robust.

[GriffinSauce]

By the way, I still like startDate as an identifier. It is nice and clear. But if another solution is better so be it.

[HalleyInteractive]

I agree, not using any time removes the need of a time zone. The current situation of indexing the periods on their start date seems to be working fine.