Datetime Format as Input to Synth Program

[Samuel Van Gorden]

Despite my reading and re-reading of the Stata manuals, the myriad of ways in which datetime variables can be stored and how they must be accessed (in addition to most of the paradigms in Stata, frankly) continues to elude me.

I have a dataset that contains data at the monthly granularity stored as e.g. "Dec 1990", "Mar 2001", etc. I have used tsset and am now attempting to pass the date "Dec 1990" into the trperiod() option of the synth program. I have tried all sorts of combinations of using date(), dofm(), tm(), etc. but Stata just laughs at me and says my syntax/type/name is invalid.

Can anyone provide some guidance as to how I can actually specify a monthly date so I can hopefully wrap this project and never use Stata again?

Thanks!

[Jared Greathouse]

When this is my problem, I'd do

u "http://fmwww.bc.edu/repec/bocode/s/scul_Taxes", clear
loc int_time: disp 
cls
qui xtset
local lbl: value label `r(panelvar)'


loc unit ="Kansas":`lbl'

cls
synth gdp avg_wkly_wage(`=tq(2008q1)'(2)`=tq(2011q3)') ///
month1_emplvl month2_emplvl month3_emplvl ///
gdp(`=tq(2011q1)') gdp(`=tq(2010q1)') gdp(`=tq(2009q1)') gdp(`=tq(2000q1)'), ///
fig trunit(`unit') trperiod(`=tq(2012q1)') nested

Here's to never using Stata again!!!!!!!

[Clyde Schechter]

I do not use -synth- myself. It is a user-written program, by the way, not part of official Stata. Nonetheless, from its help file I glean the following relevant information:

1. The data must be -xtset- or -tsset- as panel data before you use it.
2. If you time variable is really a string variable with values like "Dec 1990" then you cannot have done that since those commands do not accept string variables.
3. The value supplied in the -trperiod()- option should be a (potential or actual) value of the time variable in your -tsset- command.

So, the first step will be to convert your date variable to a proper Stata internal format date variable. Since you time variable is monthly, that would go like this:

gen time_var = monthly(string_time_var, "MY")
assert missing(time_var) == missing(string_time_var)
format time_var %tm
drop string_time_var // UNLESS YOU NEED IT FOR SOME OTHER PURPOSE

Next you need to -tsset panel_var time_var-.

Then in your -synth- command you can specify the -trperiod()- option as -trperiod(`=tm(1990m12)')-.

Despite my reading and re-reading of the Stata manuals, the myriad of ways in which datetime variables can be stored and how they must be accessed (in addition to most of the paradigms in Stata, frankly) continues to elude me.

Yes, the subject of datetime variables is extensive and complicated. I expect that nobody, except perhaps the developers at StataCorp themselves, has it all at their fingertips. But with practice, it does start to sink in. While I still have to refer to the help files for the exact names of specific functions or to remind myself which arguments go in which order, the concepts behind them are not hard. And the kind of cases that I use regularly in my work have become entirely routine and seamless. When confronted with situations I rarely encounter, I do have to consult the help files, and sometimes the documentation. So don't despair. The learning curve is steep, but the view from the top is splendid and worth the effort.
[quote]

Finally, I think what you are having trouble with here is not Stata's datetime paradigm. It's how command options work. In -synth-'s syntax, the argument specified in -trperiod()- must be a number. That means it must literally be a number. That's why ym(1990, 12) and tm(1990m12) don't work when you try to use them: they are not numbers, but rather expressions that evaluate to numbers. But Stata does not evaluate expressions when it parses the code. The only things that Stata evaluates during the parse are (local and global) macros. So the only way to pass an expression as a number argument is to do it through a macro. That's what motivates the solution I have offered you above.

To illustrate this, look at the following toy program that accepts a single number as its -prompt()- option and just prints out that number in the Results window. You can see how it responds to different ways of representing the current month, February 2023:

. capture program drop echo

. program define echo
  1.     syntax, prompt(real)
  2.     display `prompt'
  3.     exit
  4. end

.
. capture noisily    echo, prompt(757)
757

. capture noisily    echo, prompt(tm(2023m2))
option prompt() invalid

. capture noisily    echo, prompt(`=tm(2023m2)')
757

. capture noisily    echo, prompt(ym(2023, 2))
option prompt() invalid

. capture noisily    echo, prompt(`=ym(2023,2)')
757

. capture noisily    echo, prompt(monthly("Feb 2023", "MY"))
option prompt() invalid

. capture noisily    echo, prompt(`=monthly("Feb 2023", "MY")')
757

Notice that you get a result only with a number, or with a local macro that evaluates to a number. But functional expressions fail--they are not evaluated before the parse, so they are not recognized as numbers.

Added: Crossed with #2.

[Jared Greathouse]

The value supplied in the -trperiod()- option should be a (potential or actual) value of the time variable in your -tsset- command

Yep synth is pretty weird in that regard. When I was writing scul, I originally followed in this sort of way (trperiod, trunit), but then I realized that I wanted to incorporate multiple interventions, so I just forced users to specify a treated variable. This actually came in handy more than I figured it would. I wish more commands forced people to specify a treatment variable so users wouldn't have this problem, but it is what it is. Incidentally, I didn't even know this solution existed until very very recently, so now I use it all the time to specify treatments with sub-year aggregations. I used to do

loc int_time: di tq(2000q1)

And then have `int_time' be my treated date, but the solution here us much easier!

[Clyde Schechter]

[digression]

...so I can hopefully wrap this project and never use Stata again?

Here's to never using Stata again!!!!!!!

Stata is not for everybody. For that matter, statistical analysis is not for everybody. If O.P. would like to leave statistical analysis behind, so be it. If he wants to do it with another Statistical package, well, that is his right, and I sincerely wish him luck in finding a statistics package he prefers. There are several out there now, and their approaches are quite different. I have observed that in general statistical package preferences are a bit like religions: most people stick with the one they were raised on and resist alternatives pretty fiercely. Different packages really do require you to think about problems and data differently, and different people will differ in how close to their own way of thinking that comes.

For my part, my first statistical package was SPSS, to which I was introduced in the late 1970's. In the 80's I learned SAS and SYSTAT. I never felt fully comfortable with any of these packages. In 1994 I was introduced to Stata, and it was "love at first sight." I remember thinking "at last there is a statistical package that thinks about things the way I do." But, putting it tritely, many of my best friends are dedicated users of SAS or SPSS. Sometimes it gets a bit inconvenient when we have to collaborate across languages: my knowledge of both SPSS and SAS are pretty out of date, and my memory for what remains unchanged in them is faded. But we manage it adequately. When working alone I use Stata almost exclusively, with (very infrequent) resort to other packages for things that Stata doesn't do.
[/digression]