EViews.com

EViews does not seem to handle dates in a consistent fashion. The following code works just fine. (Notice in particular the date manipulation on row 4.) Whereas moving the date manipulation to line 3 causes the program to break down. The only way I can find to make the second code work is through the (quite lengthy) code below. Is there anyway less lengthy to do this? And are there intentions to make the date handling consistent?

I'm not sure I understand the inconsistency. It isn't that dates are being handled differently, you're just doing two different things.

The way you are doing the second example seems the most efficient.

Indeed you are correct that I am doing two different things. However, what I was aiming at was how the same date format, i.e. %startdate+1 (or "1970Q1"+1), is handled differently by the two commands smpl and wfcreate. When used in smpl it is understood and accepted, but in wfcreate it is not. To me, this seems an inconsistency.

Moreover, moving the date manipulation in the third code from my last post down to the wfcreate line also causes the program to break down. IMHO there should not be any difference between how EViews handles a variable which has been declared to contain a value and how EViews handles that same value if entered directly.

One small consolation is that this odd behavior at least seems to be consistent. Replacing %startdate+1 in the second code from my last post with @datestr(@dateadd(@dateval(%startdate,"YYYY[Q]Q"),+1,"Q"),"YYYY[Q]Q"), as per the code below, also causes the program to break down.

How would the wfcreate command know what "1" is?

Ah, I see your point. However, frequency is specified earlier on the very same line.

Do you have any input on my second issue?

Neither the WFCREATE command nor the SMPL command take strings as arguments (the fact that you can enclose the arguments in quotes if you want does not mean that they actually take strings as arguments). Thus you cannot use functions that return strings as arguments.