New time types, relationships between time types

[ajaynshah]

Consider the CMIE CPHS notion of a "wave". Their clock is wave1-2019, wave2-2019, wave3-2019, wave1-2020, etc., with 3 waves a year that (in turn) map to fixed months: wave 1 is always jan-feb-mar-apr.

This made me think:

a. How would an end-user tell TSFrames.jl that this is a new kind of desired time index?

b. I wonder if there are angles for interesting automated operations where we exploit the knowledge that q1-2019 (which is a yearqtr) is the same as jan-feb-mar 2019 (i.e. three different yearmons).

[chiraganand]

Consider the CMIE CPHS notion of a "wave". Their clock is wave1-2019, wave2-2019, wave3-2019, wave1-2020, etc., with 3 waves a year that (in turn) map to fixed months: wave 1 is always jan-feb-mar-apr.

This made me think:

a. How would an end-user tell TSFrames.jl that this is a new kind of desired time index?

Currently, TSFrames does not support custom index type. Only <: TimeType and ::Int index types are supported.

I can imagine a new Wave type could be created which is a extends TimeType and then can be used with TSFrames. All the time types are, essentially, integers (millisecond/nanosecond) under-the-hood so it should be possible to construct a wave type using these fundamental blocks.

b. I wonder if there are angles for interesting automated operations where we exploit the knowledge that q1-2019 (which is a yearqtr) is the same as jan-feb-mar 2019 (i.e. three different yearmons).

I feel one should be able to exploit Date module features by doing a correct implementation of wave type described above. Are you looking for something specific though?

[ajaynshah]

a. We are all extensively using CPHS so Yes, support for the wave type would be nice.

b. What would be even better is if TSFrames has a general technology for new concepts of time which are user defined. And then this is a special case which is shown as an example.

c. On "interesting automated operations" I'm just thinking aloud around automated aggregate() rules. Imagine if I know that a quarter is three consecutive months. And imagine if all the time-series of the world are classified into stocks and flows [this is economist speak: anything that has a unit which is per time is a "flow" and where it's not per time it's a "stock"]. Now certain default rules of monthly2quarterly() can kick in. If you show me a stock (e.g. an exchange rate) then the right way to convert from a monthly TS to a quarterly TS is to take the value from the last month of the quarter. If you show me a flow (e.g. trading volume, is shares per day) then the right aggregation technique is to sum up the months that make up the quarter.

Of course, the user will have overrides and special cases, and at present we support all of them. My reasoning here feeds into default rules where TSFrames can exploit the fact that it knows that w1 is the months jan-feb-mar-apr for default aggregate() operations.

[chiraganand]

Of course, the user will have overrides and special cases, and at present we support all of them. My reasoning here feeds into default rules where TSFrames can exploit the fact that it knows that w1 is the months jan-feb-mar-apr for default aggregate() operations.

This should be possible. aggregate() methods can be written (overloaded) for user-defined Wave type so that Julia dispatches these methods when eltype(index(ts)) == 'Wave'.