EViews.com

I've been using the @makedate function in some of my code and it's been working fine up until this month.

As an example, the following code for January 2013 generates the value 735141: But, the following code for February 2013 generates NAs: Can you explain why there's a difference? My workfile is monthly and has a range of 1975:01 to 2014:12.

I'm using Eviews 7.2 with the Oct 17 2012 build.

"yyyy.mm" implies a two digit month. "1" is being treated as a 10 (i.e. the last zero is assumed). Thus the code for January actually creates a value equal to October.

The "2" gets treated as a 20, and there is no 20th month, so it makes an NA.

Oops ... I see now that our data last month was labeled as October 2013.

Shouldn't this date format assume a leading zero instead of trailing zero?

The description of date formats in the Eviews 7 Command Reference shows acceptable month strings as:
• “mm” or “MM”: two-digit month without/with leading zeros.
I interpreted this to mean that the upper-case "MM" format was to be used when you were always working with 2-digit months (i.e. 01,02,03,...,10,11,12). And the lower-case "mm" format was to be used when you were working with 1- or 2-digit months (i.e. 1,2,3,...10,11,12).

Also, one of the examples for @makedate in the Command Reference's description of string and date functions states that @makedate(1990.3, "yyyy.mm") will return a value of 726526.0 (March 1, 1990). However, when this example is used in a genr command the code returns NA for the reason you state above.

It appears that Eviews interprets all three of the following commands as October 2013: Is there any other date format that I can use to get 2013.1 interpreted as January 2013 (without having to manually insert a leading zero - 2013.01)?

The problem is that @makedate takes a numeric value as input, which means that the two values:

2013.1
2013.10

look exactly the same as far the @makedate function is concerned. (The conversion to a numeric constant occurs before the @makedate function ever sees the input). This means that only 2013.01 can be treated as January when working with the numeric form of yyyy.mm format.

If you have a choice, you're almost always better off using @dateval() which takes a character string value as input. The two string values:

"2013.1"
"2013.10"

are not the same, and the @dateval function will be able to treat them as different months of the year (with format "yyyy.mm").

If you're just after date constants for months, the simplest form is:

series ser01 = @dateval("2013m1")

where the 'm' makes the period unambiguous so no format string is required.

We support conversion out of the numeric form of yyyy.mm because sometimes incoming data has values in this format (typically from packages that don't support strings or true calendar dates). It's not a great format because it tends to lead to exactly the sort of problems that you describe. (And you're clearly not alone - the example in our manual is incorrect for the same reason - we'll fix this).

Sorry for any confusion.

Chris

Thanks for the suggestion. Now I understand the logic behind how the function works.

The users of our Eviews code generally don't enter in a leading zero when inputting the month, so that's why we're hoping for more flexibility in our code.

I think we can work with your suggestion to structure the string as, e.g., "2013m1" (%year+"m"+%month) instead of "2013.1" and use the @dateval function instead of @makedate.

This might actually be a more appropriate choice since we also use the string when setting sample periods in our code, in addition to labeling the date of the output data.