Introduction to TimeSeries
Introduction to TimeSeries
See also TimeSeries(), Entities
What is a TimeSeries?
A TimeSeries is a series of records consisting of dates and values, associated with an entity, and stored in the Quintessence database along with other related information. The TimeSeries() function retrieves the records and associated information for a specified range of dates.
For example, this figure shows daily Close Prices for instrument VRR for a range of dates (29 April 2015 to 5 May 2015):
Some information pertains to all points in the series:
![]() |
Example values |
Entity | VRR |
Factor | Close Price |
Unit | GBP |
Period | Daily |
Source | MarketDataProvider1 |
Attributes | Interim figures |
Some information is unique to each point in the series:
![]() |
Example values |
Value | 56 |
Value date | 30 April 2015 |
Declaration date | 30 April 2015 |
Note:
- TimeSeries values can be numeric or text, for example, a ‘Name’ TimeSeries for a company or country would have text values.
- The declaration date can be different to the value date, particularly in the case of forecast values that are declared or revised on a single date, and also in the case when actual values are revised.
TimeSeries data
Entity
An entity is identified by a code and has data associated with it, for example a portfolio, instrument or country. See more on Entities.
Factor
The factor is the type of value being requested as a series, for example, Close Price, Holding, Market Value, Turnover, Profit and Loss etc.
Entity | Value Date | Close Price |
GMP | 1 June 2015 | 24.5 |
GMP | 2 June 2015 | 23.7 |
GMP | 3 June 2015 | 23.4 |
Unit code
A unit code can be attached to the TimeSeries, such as currency code, country code, language code or exchange code. For example, the Accrued Income TimeSeries for fund ABC123 is associated with the currency GBP and ZAR. Therefore the TimeSeries can be requested as a series of GBP or ZAR values by stipulating which unit code to use.
Entity | Value Date | Accrued Income (GBP) | OR | Entity | Value Date | Accrued Income (ZAR) |
ABC123 | 1 June 2015 | 5000000 | ABC123 | 1 June 2015 | 95000000 | |
ABC123 | 2 June 2015 | 5000100 | ABC123 | 2 June 2015 | 95001900 | |
ABC123 | 3 June 2015 | 5000150 | ABC123 | 3 June 2015 | 95002850 |
Using ‘*‘ as the unit code parameter value will return values for all unit codes.
Entity | Value Date | Unit code | Accrued Income |
ABC123 | 1 June 2015 | GBP | 5000000 |
ABC123 | 2 June 2015 | GBP | 5000100 |
ABC123 | 3 June 2015 | GBP | 5000150 |
ABC123 | 1 June 2015 | ZAR | 95000000 |
ABC123 | 2 June 2015 | ZAR | 95001900 |
ABC123 | 3 June 2015 | ZAR | 95002850 |
Period
The period related to the TimeSeries values under consideration. For example, Close Price is daily and earnings per share (EPS) is annual. High Price could be daily, weekly, monthly, quarterly and annually.
Examples |
D (day) |
W (week) |
M (month) |
Y (year) |
NA |
Source
Simple sources
The source(s) of the TimeSeries under consideration.
Examples |
MarketDataProvider2 |
PortfolioAdministrator1 |
MarketDataProvider1 |
StockExchange1 |
Note:
If more than one source is provided, there must be a one-to-one relationship with the factors requested. For example, TimeSeries(‘XYZ‘, ‘Close Price, High Price‘‘‘.‘MarketDataProvider1, MarketDataProvider2‘‘), will return Close Prices sourced from MarketDataProvider1, and High Prices sourced from MarketDataProvider2.
Custom sources
The source parameter can also accept a custom TimeSeries source or custom Relationship source that has been constructed in the Quintessence system. These underlying custom TimeSeries and Relationships can be constructed using multiple building blocks and can be derived from multiple sources.
For example, the following TimeSeries() function takes a custom source ‘TotalReturnEquity’ as a parameter:
In this example, ‘TotalReturnEquity‘ is a custom source that has been constructed in Quintessence. It draws data from a number of sources. More on custom sources and how to construct custom sources…
Attribute set
The attribute(s) of the TimeSeries values under consideration.
Examples |
Historical |
Forecast |
Final |
Interim |
Quarter |
TimeSeries point data
Value
The numeric or text value of a point in the series, for example the Close Price for a specific date.
Entity | Value Date | Value |
QGW | 4 May 2015 | 45 |
Value date
The date which the value of a point in the series is relevant to.
Entity | Value Date | Value |
QGW | 4 May 2015 | 45 |
QGW | 5 May 2015 | 47 |
QGW | 6 May 2015 | 49 |
Declaration date
The date on which a set of values or value was declared (made available to the market). Values can be revised; therefore a value date can occur more than once in the data for different declaration dates, and the declaration date may be different to the value date.
Entity | Value Date | Value | Declaration date |
QGW | 4 May 2015 | 45 | 4 May 2015 |
QGW | 5 May 2015 | 47 | 5 May 2015 |
QGW | 6 May 2015 | 49 | 6 May 2015 |
QGW | 5 May 2015 | 47.1 | Revised: 1 June 2015 |
QGW | 6 May 2015 | 48.6 | Revised: 1 June 2015 |
TimeSeries function
The TimeSeries() function retrieves TimeSeries data from the database.
Note:
For reference help on the function syntax and to view examples, see TimeSeries().
Values are requested for an entity between a specified start date and end date, and also for a specified frequency (daily figures, monthly, trading days only etc.). An Information As At Date (IAAD) requests information that was known at the time of the IAAD. When left blank, the IAAD defaults to today’s date.
TimeSeries delimiters | Example |
Start date | 1 June 2015 |
End date | 5 June 2015 |
Frequency | TD (Trading days only ) |
Information As At Date (IAAD) | 30 June 2015 |
Start date
The date delimiting the start of the value date range under consideration.
End date
The date delimiting the end of the value date range under consideration.
Frequency
Examples | Trading days only |
D (day) | TD |
WS (week starts) | TWS |
WE (week ends) | TWE |
MS (month starts) | TMS |
ME (month ends) | TME |
QS (quarter starts) | TQS |
QE (quarter ends) | TQE |
YS (year starts) | TYS |
YE (year ends) | TYE |
P (any point with values) |
Information as at date
The information as at date (IAAD) requests information that would have been available at that point in time. Any information declared after the IAAD is ignored.
Consider the following set of information, declared on the dates shown on the horizontal axis (in this example, today’s date = 1 Jan 2016):
A TimeSeries() function that requests values between 1 Jan 2009 and 1 Jan 2016, with an Information As At Date = ‘1 July 2013’ would return the values below. All values declared after the IAAD are omitted:
A TimeSeries() function that requests values between 1 Jan 2009 and 1 Jan 2016, with an Information As At Date = ‘1 July 2015’ would return the values below. All values declared after the IAAD are omitted:
Default values
Implicit defaults
In cases where there is only one option to use as a parameter value, for example, Period = ‘D‘ or Unit= ‘ZAR‘, the TimeSeries() function parameter value can be left blank and will default to the only available option. In this example, the parameters for Unit, Period and Attribute can be left blank, as the values will default to the only values possible (ZAR, D and Historical respectively):
Where more than one option is possible, for example, information is stored per day and per week, or comes from more than one source, the value needs to be explicitly provided to the TimeSeries() function, either by the user, or by setting up explicit defaults for that context (the combination of parameter values that are supplied).
In the example above, there are three possible data sources ‘ MarketDataProvider1, StockExchange1 and PortfolioAdministrator1 ‘ so the source needs to be explicitly specified in the function.
Explicit defaults
Default values for ‘Source’, ‘Period’, ‘Unit’, ‘Interpolation’ and ‘Attribute’ can be set up by the system administrator. These default values are context specific, in other words they can be set for specific Entities, Users, TimeSeries, Sources, Periods, Units and Attributes, or for combinations of these.
If a user enters a TimeSeries function, but does not specify the Unit, any explicit default values specific to that context are used. If there are no explicit defaults, and there is only data for one option in the database, the implicit default is used. If there are two possible options in the database, and the user does not specify which one to use, and there is no explicit default set for the context, no values are returned, as the request cannot be resolved.
For example, if the user specifies ‘ZAR’ as a unit, ‘ZAR’ will be used. If the user does not specify a unit value, first the explicit default will be used. If there is no explicit default specified, an implicit default will be used, if possible. In the latter case, if there are two possible options for unit (data exists for both), no values are returned.
Scenario | Outcome |
Explicit default = GBP, user stipulates ZAR | ZAR is used |
Explicit default = GBP, user omits value | GBP is used |
No explicit default is set, user stipulates ZAR | ZAR is used |
No explicit default is set, user omits value |
If data exists for one unit option (e.g. GBP), the data is returned. If data exists for more than one unit option (e.g. ZAR and GBP), no data is returned as the request can’t be resolved. |
System defaults
Universal defaults can be set up in the system, such as the exchange to use.
Interpolation/extrapolation
Interpolation is an estimation of an unknown value on a value date that occurs after a known value or between two known values in a sequence. Extrapolation is an estimation of a value beyond a known sequence of values. Interpolation can be Linear, Forward or None. Extrapolation can be Forward or None (it cannot be linear as there is no known value after the missing value to use to plot a linear graph).
In the following TimeSeries, values are missing for value dates 31 March 2012 and 1 April 2012, possibly because those two days fell on a weekend or were not trading days. It can be useful to estimate the missing values, using the values that are known.
Interpolation
Forward interpolation
The figure below illustrates forward interpolation, where the last known values are brought forward as estimate values for the missing values in the series:
Linear interpolation
The figure below illustrates linear interpolation. A straight line is plotted between the last known values and the next known values in the series. Where the line intersects with the value dates of the missing values determines the estimated value:
Figure 5. Linear interpolation
TimeSeries function example
Consider the following TimeSeries() function:
Note that the output is missing values for weekend value dates:
Change the Interpolation parameter to ‘forward‘:
The last known values are carried forward:
Change the Interpolation parameter to ‘linear‘:
Values are plotted between the last known and next known values. The intersection of that line with the value date of the missing values determines those values:
Extrapolation
Extrapolation happens outside the known data range and therefore can only be Forward or None (there is no future value which can be used for a linear extrapolation).
The * parameter
Sometimes it is useful to return the data for all declaration dates, for example when looking at the movements in values after revisions have taken place. Using ‘*‘ as a parameter value in place of a declaration date returns the values for all declaration dates.
This is especially useful in the case of snapshots, as one can retrieve data for all declared snapshots for comparison purposes.
Snapshot TimeSeries
Note:
Snapshot TimeSeries are specialised TimeSeries used by advanced users when loading data into Quintessence. Examples would be when analysts enter series of forecast values for EPS, each series forming a snapshot with its own declaration date.
A TimeSeries can be flagged as a ‘snapshot‘ TimeSeries in Quintessence, for example a Yield Curve or set of forecast EPS values. All values declared on a single declaration date form a single snapshot.
Consider the following stored data and two subsequent TimeSeries() function calls. The values were declared on 10 October 2015 and revised on 15 October 2015:
A TimesSeries() function call to retrieve these values will behave differently in the case where the stored data is defined as a snapshot from where it is not defined as a snapshot.
Non-snapshot TimeSeries
In the case where the stored data is not defined as a snapshot, and the values are requested with an IAAD of 15 October 2015, the latest declared values for a value date will be returned, regardless of the declaration date, but provided the declaration date is on or before the IAAD. Anything declared after the IAAD will be omitted from the output. The output is as follows:
Note: although the value for 3 October 2015 (green dot) has a different declaration date to the other values (purple dots), it is the most recently declared value for that value date and is included in the output.
Snapshot TimeSeries
In the case where the stored data is defined as a snapshot, and the values are requested with an IAAD of 15 October 2015, only values declared on that date will be returned. The output is as follows: