Issue with misaligned annual data download in eviews
Hi @andrew.harris,
Would you mind letting us know what instrument/code/mnemonic you are experiencing this issue with?
It would be preferable to know the time-span and frequency of data you are requesting too.
Hi @andrew.harris,
Using the Python API, this is what I get:
df6 = ds.get_data(tickers="BDWOGDP.C", fields="X", start='1980-01-01', end='2021-01-01')
Instrument: BDWOGDP.C
Field: X
30/06/1980: 1683.16
30/06/1981: 1685.02
… …
28/06/2019: 3232.34
30/06/2020: 3073.85
30/06/2021: 3184.58
May I ask (i) is this the data you are receiving on your end? And (ii) what are you comparing incoming data to?
It could be that, due to the fact that this data is only published in Datastream after the 1st of June of every year, it defaults to the year above, like a rounding up issue; however this should have been an issue seen in the past, and you say that this is a new problem you've never encountered before with this BDWOGDP.C instrument, correct?
I asked internally for someone with EViews access to look into this, he will be getting back to us tomorrow.
As the returned dates are the start of the period (06/30/1980), technically the data range for that observation is 06/30/1980-06/29/1981. EViews however will only pull off the year value and therefore think the date range is (1/1/1980-12/31/1980).You should speak with EViews directly how to best align your series.
After discussions with EViews the function CSR# continuous series will resolve this issue of misalignment . CSR# enables you to convert a series from one update frequency to a pseudo-series with a higher frequency. For example, a series with a monthly frequency can be converted to a pseudo-series with a daily frequency. This means that you can combine series with different update frequencies in a single expression and display consistent values for the whole expression.
Any datatype can be transformed to a higher frequency via CSR#(X) or CSR#(X,N). These expressions make no change to the underlying datatype’s values but simply show the values at a higher frequency. Plain CSR#(X) pads the output series to request end date unless the datatype is economics for which the padding ends on the actual date of the request.
The parameter N means that values at the higher frequency are not displayed beyond the month, quarter or year of the last updated value on the database, depending on the underlying datatype’s frequency.
For economic series, one can also use linear interpolation to create the higher frequency values. That is achieved via one of the parameters D, M or Q. The original values are then interpolated as described below. The higher frequency data series will not extend beyond the latest date for which there is a value of the underlying datatype.
The format is CSR#(series,X), CSR#(series,D), CSR#(series,M), CSR#(series,Q), CSR#(series,N)
The rules are as follows and are dictated by the frequency conversion datatype ECONV:
If ECONV = AVERAGE (as is the case with USGDP…D) then the actual quarterly number is placed in the mid month of the quarter, and then the intervening 2 months are linearly interpolated between the mid-quarter numbers.
If ECONV = END POINT (as is the case with US64MGTLA, mortgage debt of the US financial sector) then the actual quarterly number is placed in the last month of the quarter, and then the intervening 2 months are linearly interpolated.
If ECONV = SUM (as is the case with EKGDP…D) then one-third of the quarterly number is placed in the mid month of each quarter, and then the intervening 2 months are linearly interpolated between the mid-quarter numbers.
Format
CSR#(Expression,Optional Parameter)
Where Optional Parameter can be D (Daily), M (Monthly), Q (Quarterly) or N (No values display beyond latest value on the database)
Example
CSR#(USGDP…D,M)
This converts the quarterly US GDP series to a pseudo-monthly series.
Limitations
The D (daily) optional parameter for CSR# is not currently supported by AFO in the Functions selector, Intellisense or Expression Builder, however it can be used directly in requests. It is fully supported in DFO and Datastream Charting, including the web Expression Builder.