1
●0 ●1 ●1
Issue with misaligned annual data download in eviews
Hi, I'm currently trying to download annual data from Datstream directly into eviews using the fetch command. However each time I attempt this, the downloaded data appear misaligned (i.e. 1980 is displaying the 1981 data point). I was wondering whether there was some kind of fix for this. Thank you in advance for any help you can provide, Andrew
1.4k
●6 ●2 ●2
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.
1
●0 ●1 ●1
Hi, thanks for getting in touch. The code I'm trying to use is BDWOGDP.C though I am having this issue with other annual codes too. I've been trying to request the data over the whole time period (so 1980 to 2026 at an annual frequency) but it seems to be misaligning by one year. What I'm doing is either typing fetch(d=dst, link, m) BDWOGDP.C into the command bar or selecting the fetch command from the eviews workfile. I haven't encountered this problem before but it just seems to have started recently. Thanks
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?
1
●0 ●1 ●1
Thanks. Yes, those are the numbers I get but all shifted by one year (so 1683.16 would appear as the 1979 value). I've been cross-checking these against what I can download through the excel addin (and also directly to the raw IMF data) and it does seem to be out by one year. As you say, it's odd as I've not experienced this before and have been using eviews for some time and not noticed this in previous years.
Hi
@andrew.harris,
I asked internally for someone with EViews access to look into this, he will be getting back to us tomorrow.
41
●0 ●0 ●0
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.
Hi James. Thanks for getting in touch. I'm not 100% sure I understand your answer. If I take the Germany example, the first data point as viewed in Datastream is for 30/06/1980. In your example, that should encompass the date range 30/06/1980 - 29/06/1981. But when I download into eviews, the date displayed for that observation will be 1979 which doesn't seem to make much sense. What's interesting is that this never used to be an issue but has become so in the past few weeks. I haven't updated my eviews in that time which is why I assumed it must have been something that's changed in the Datastream API. Do you think that could be the case? Thanks, Andrew
41
●0 ●0 ●0
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.
