Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Setting string ID and string time variable - Panel Data

    I have a quarterly panel data of 20 countries from 2000q1-2012q4. When I import the excel file, both the variables (country and date) turns out to be string variables (appears red in data browser).
    Here is the description of the two variables: (for ease of reference, I have dropped dependent and independent variables)

    Code:
    . des
    
    Contains data
      obs:         1,040                          
     vars:             2                          
     size:        21,840                          
    -------------------------------------------------------------------------------------------------------------
                  storage   display    value
    variable name   type    format     label      variable label
    -------------------------------------------------------------------------------------------------------------
    country         str14   %14s                  Country
    date            str7    %9s                   Date
    -------------------------------------------------------------------------------------------------------------
    Then I use the following command to encode the string country variable and now it appears blue in data browser

    Code:
    . encode country, generate(country_n)
    
    . des country_n
    
                  storage   display    value
    variable name   type    format     label      variable label
    -------------------------------------------------------------------------------------------------------------
    country_n       long    %14.0g     country_n
    1. Is it correct?
    2. How to convert the date variable correctly? When I create a date variable, I do manage to create the correct date variable but it does not take into account that the data is a panel. Instead of restarting from 2000q1 it continues from 2012q4 (for example, when the first country is completed for the next one date become 2013q1 instead of 2000q1). Alternatively, can I just derive the date variable for the first ID and then keep copy/pasting for the remaining?

    Date appears as follows:

    Code:
     list country date in 1/10
    
         +----------------------+
         |    country      date |
         |----------------------|
      1. | Argentina    2000-q1 |
      2. | Argentina    2000-q2 |
      3. | Argentina    2000-q3 |
      4. | Argentina    2000-q4 |
      5. | Argentina    2001-q1 |
         |----------------------|
      6. | Argentina    2001-q2 |
      7. | Argentina    2001-q3 |
      8. | Argentina    2001-q4 |
      9. | Argentina    2002-q1 |
     10. | Argentina    2002-q2 |
         +----------------------+



  • #2
    You don't show any code for how you attempted to convert your date variable, so it is anybody's guess what went wrong.

    Here is how I would handle this data:

    Code:
    * Example generated by -dataex-. To install: ssc install dataex
    clear
    input str9 country str7 date
    "Argentina" "2000-q1"
    "Argentina" "2000-q2"
    "Argentina" "2000-q3"
    "Argentina" "2000-q4"
    "Argentina" "2001-q1"
    "Argentina" "2001-q2"
    "Argentina" "2001-q3"
    "Argentina" "2001-q4"
    "Argentina" "2002-q1"
    end
    
    encode country, gen(n_country)
    
    gen qdate = quarterly(date, "YQ")
    assert missing(date) == missing(qdate)
    format qdate %tq
    
    xtset n_country qdate
    In the future, when showing data examples, please use the -dataex- command to do so, as I have in this response. If you are running version 16 or a fully updated version 15.1 or 14.2, -dataex- is already part of your official Stata installation. If not, run -ssc install dataex- to get it. Either way, run -help dataex- to read the simple instructions for using it. -dataex- will save you time; it is easier and quicker than typing out tables. It includes complete information about aspects of the data that are often critical to answering your question but cannot be seen from tabular displays or screenshots. It also makes it possible for those who want to help you to create a faithful representation of your example to try out their code, which in turn makes it more likely that their answer will actually work in your data.


    Comment


    • #3
      Thanks for your response. It works.

      Earlier for date I was using :
      Code:
      tsmktim date1, start(2000q1)
      Lastly, the ID variable (country) as earlier appears to be in the long format and blue in data browser. Is it because the country variable is not numerical? STATA manual states: to distinguish between different types of variables in Data Editor value labels are displayed in blue.

      Comment


      • #4
        -tsmktim- is not part of official Stata. It is a user-written command, and I am not familiar with it, so I can't help you troubleshoot that code. In any case, the code given in #2 accomplishes the task.

        If you have not changed the default settings for display preferences, then, yes, a variable that is displayed in blue in the data browser/editor is a numeric variable with value labels. If the variable were actually a string, it would display in a color that the Stata manual refers to as red, although on some displays it looks more brown. Numeric variables without value labels are displayed in black.

        For Stata calculations involving dates, it is essential the the date variable be a numeric variable, and that it be a correct Stata internal format date variable. Stata has date time display formats which enable you to see in human readable form the dates that these Stata internal format date variables refer to. As with other display formats, they do not affect the color in which the variable is shown in the browser: it is still black.

        If you have a numeric variable that has value labels that look like dates to human eyes, it is very likely incorrect and results of using it as a date variable in Stata will usually be seriously wrong.
        Last edited by Clyde Schechter; 20 Jul 2019, 15:12.

        Comment


        • #5
          All right, thanks for the explanation.

          Comment

          Working...
          X