Appendix 6: Event History Creation and Documentation

• Employment
• Marriage and Cohabitation
• Program Participation
• Schooling

Return to Table of Contents

The NLSY97 survey records significant life-course transitions experienced by young people, such as education, employment, program participation, and marital history, in a longitudinal format.  The event history arrays document these events in a chronological format that records the significant transitions in a meaningful manner while maintaining data quality.  Using these arrays, researchers can extract the status of a respondent at a point in time or over time.  Event history arrays are generated for four distinct areas:  employment, marital/cohabitation status, program participation, and schooling.  This section presents information on each type of event history array; for details on the chronological format of the arrays and the naming conventions used to identify the variables, users should refer to Appendix 7.

Employment Event History Arrays

Three employment arrays provide information on the respondent's civilian employment on a weekly basis.  These arrays include information about employee jobs only; freelance jobs are not included in the arrays.  All employment arrays provide information starting in the month when the respondent turned 14 and ending in the week that he or she was last interviewed.

1.  EMP_STATUS
This main array presents the civilian employment status of a respondent in a particular week.  The codes and their explanations follow:

2.  EMP_DUAL_JOB#
If a respondent holds more than one civilian employee job during a week, the second employee job is presented in a dual job array.  These arrays contain only the job number of the overlapping job; labor force status information is only included in the main array.  For example, if a respondent held two civilian employee jobs (e.g., the first and third jobs listed on the employer roster) in one week, the employer number for the first job would be recorded in the EMP_STATUS array and the employer number for the third job would be recorded in the EMP_DUAL_2 array.  If a respondent held three jobs (e.g., jobs #01, #04, and #05 on the roster) in one week, the first job would be recorded in the EMP_STATUS array, the employer ID for job #04 would be recorded in the EMP_DUAL_2 array, and the employer ID for job #05 would be recorded in the EMP_DUAL_3 array.  Unlike the NLSY79 work history arrays, jobs are recorded in the status and dual jobs arrays based upon the order presented in the employer rosters.

3.  EMP_HOURS
This final array calculates the total number of hours worked by a respondent at any civilian employee job during each week.  Hours per week worked at each job are assumed constant except during a reported gap, when the hours for that job are assumed to be zero.  Each week is assigned a code of ‘-3 (invalid skip)' when any of the jobs has an indeterminate gap date.

Other Information
Continuous week crosswalk.  A secondary set of variables translates the reported beginning and ending dates (day, month, and year) of employee jobs and the gaps within those jobs to the week and year naming scheme (e.g., EMP_GAP_START_YEAR.01.01 and EMP_GAP_END_YEAR.01.01 provide the start and end dates of the respondent's first gap at the first job in the continuous week and year format).  More information about the week and year naming scheme is provided in appendix 7 in this document.

Linking to survey data using unique ID codes.  The created event history variables can be used in conjunction with the main file information about the respondent's employment.  The 9701-9707, 9801-9809, 199901-199909, 200001–200009, and 200101–200108 codes that appear in the status and dual job arrays are unique employer ID numbers that are also used in the main file data.  In the main data, these codes are listed under the question name YEMP_UID.xx (e.g., R24761.).  Using these unique ID codes, researchers can identify the comparable job information (e.g., complete start and stop dates, fringe benefits, job satisfaction, industry and occupation, etc.) from the main file.  Employers first reported in the round 1 interview have codes beginning with "97"; new employers in round 2 were assigned codes beginning with "98."  Beginning in round 3 the ID codes were assigned using a 4-digit year, so each round 3 code begins with “1999,” round 4 codes begin with “2000,” and round 5 codes start with “2001."  This system permits users to link employers across survey rounds and across data files and to identify the round in which an employer was first reported.

Denial of previously reported employers.  Respondents sometimes deny that they ever worked for an employer reported in a previous round.  If this situation occurs, the data for that employer remain in the event history arrays, but a flag variable (EMP_DENY) indicates that the employer was denied in a subsequent round.  For example, assume that a respondent reported working for employer number 9802 from January 1, 1998 through the round 2 interview date.  In round 3, however, the respondent stated that he or she never worked for that employer.  The weekly STATUS variables for January 1, 1998, through the round 2 interview date will continue to report the respondent's status as working for employer 9802, but the EMP_DENY variable will also have a value of 9802, indicating that the respondent denied working for that employer during the round 3 interview.

Missing and imputed values.  Occasionally, respondents cannot provide information about the start and end dates of employment periods or gaps in employment.  Because dates of employment are often used in subsequent questions in the jobs section, default values are substituted for these missing values so that the interview program can continue.  The missing values are then reinserted in the public use data file so that researchers will know the true value.  However, to follow the flow of an interview, users may need to understand what values were substituted so that the correct question path can be followed.  Similarly, in the creation of the event history arrays, some missing values are imputed.  Imputation rules and the effect of each on the event history arrays are as follows:

Respondents may have more than one job in a given week due to the imputation of dates as described above.  If the month or year was imputed for one job, resulting in the assignment of zeros to a given set of weeks, but another job with known dates falls in some of those weeks, the zeros will be dropped and replaced by information about the known job.  However, the respondent will not be listed as having a dual job in those weeks.  The imputed employer will not be listed in any array if the zeros are dropped because another job provides valid information.

Backreporter variables.  Some respondents report during the current interview a new job with a start date prior to the date of the last interview that was not reported during that interview. If these jobs had been reported at the previous interview, the weeks and hours worked would have been represented in the arrays at that time. When they are instead reported in the current interview, the event history arrays created at the previous interview date are not changed to include information about these new jobs. Three “backreporter” variables alert users to changes that would have resulted if the jobs had been correctly reported during the previous interview.

The first variable, EMP_BK_WKS, tells how many weeks before the previous interview date the job started. The second and third variables show how the status and hours arrays would have been affected had the job beginning before the date of last interview been reported at the prior interview and included in the original array construction. One variable, EMP_BK_STATUS, indicates the number of weeks from the job’s start date to the date of last interview for which a nonworking status would have changed to an employer ID had the job been reported during the previous interview round. The other variable, EMP_BK_HOURS, informs users about the additional number of hours per week worked on this job for the weeks from the job’s start date to the date of the previous interview. 

For example, assume a respondent named Mary was interviewed on January 15, 1999 (round 3), and January 15, 2000 (round 4). In round 3, Mary reported no employers.  In round 4, she reported working 30 hours a week on a job that began on January 1, 1999. Since the job began 2 weeks before the round 3 interview, EMP_BK_WKS would have a value of 2. EMP_BK_STATUS would also have a value of 2, indicating that 2 weeks in the round 3 arrays would have changed from nonworking to working status. EMP_BK_HOURS would have a value of 30, indicating that 30 additional hours would have been worked in each of those weeks.

Similarly, assume a respondent named John was interviewed on the same dates as Mary in rounds 3 and 4. In round 3, John reported a job that he had worked at for 10 hours per week since the round 2 interview. In round 4, he reported a second, 20 hours-per-week job that began on January 1, 1999, 2 weeks before his round 3 interview. Like Mary, John would have a value of 2 for the EMP_BK_WKS variable. However, the weeks between January 1 and January 15, 1999, would already indicate that John was working (at the original employer). Therefore, EMP_BK_STATUS would have a value of 0, because no weeks would have changed from nonworking to working status if John had reported the new job in round 3. EMP_BK_HOURS would have a value of 20, indicating the number of hours per week that John worked at the new job. In John’s case, the hours worked array variables created in round 3 would have a value of 10, reflecting the job he reported in round 3. Researchers can add the value of EMP_BK_HOURS to the value in the original round 3 arrays for the 2 weeks before January 15, 1999, to determine that John worked 30 hours per week in those weeks.

Return to top

Marital Status Event History Arrays

The NLSY97 marital and cohabitation arrays record changes in the respondent's marital status and cohabitation changes on a monthly basis.  The marital/cohabitation history program converts dates reported in the marriage section (beginning and ending dates of cohabitations, marriages, separations, divorces, and widowhoods) to an actual month number, using January 1980 as month #1.  Used jointly, these arrays allow the researcher to obtain a detailed history of the respondent's partners and changes in his/her marital and cohabitation status on a monthly basis.  All marital/cohabitation arrays provide information beginning in the month that the respondent turned 14 (although respondents do not answer marriage and cohabitation questions until they reach age 16) and ending in the month that he or she was last interviewed.  Additionally, the beginning dates of the youth's first marriage and first cohabitation are provided in two variables:  CV_FIRST_MARRY_MONTH and CV_FIRST_COHAB_MONTH.  Note that the continuous month variables reporting the births of the respondent's children (e.g., CV_CHILD_BIRTH_MONTH.01) permit easy comparison of the timing of marital and fertility events.  These variables are described in Appendix 3.

Three types of arrays record transitions between living without a partner of the opposite sex to cohabiting or to marriage.

1.  MAR_STATUS
The main array presents the status (e.g., never married/not cohabiting, cohabiting, married, divorced) of a respondent during a particular month.  Marital status takes precedence over cohabiting; for example, if a respondent is divorced and living with another partner, the status listed in this array will be ‘divorced.'  Respondents who are married but not living with their spouse are coded as married.  If a respondent reports an annulment, the previously reported dates of marriage are maintained and the marital status code after the annulment is ‘divorced.'

2.  MAR_COHABITATION
This second array details the partner that the respondent is living with in a particular month.  For example, if the respondent is cohabiting, the variable for each month identifies whether the respondent lives with partner 1, partner 2, spouse 1, spouse 2, etc.  Users should note that "1" and "2" in this case refer to the respondent's partners/spouses in chronological order.  The numbers do not necessarily refer to the same person as the loop numbers in the spouse/partner questions asked directly of the respondent during the survey.  Users can distinguish between partners and spouses because partner IDs begin with "1" (e.g., 101, 102) and spouse IDs begin with "2" (e.g., 201, 202).

3.  MAR_PARTNER_LINK
The third array links the cohabiting partner or spouse to the partner order in the main survey questions.  This array allows the researcher to identify characteristics of the respondent’s partner and to link them with spells of marriage or cohabitation.  For example, a researcher might look at the MAR_COHABITATION variable for the 9^th month of 1998 and determine that a respondent was living with his second partner ever in that month because the variable’s value is 102.  The MAR_PARTNER_LINK variable provides a crosswalk between this value and the new partner ID variable on the partner roster (PARTNERS_ID ).  The researcher can then examine the roster and survey variables with for that partner to determine the person’s characteristics, such as race, ethnicity, age, religion, and so on.  However, if there is a significant gap between relationship spells—for example, if the respondent was married and then divorced a spouse before round 1 and then began cohabiting with the same person in round 3—the survey would not necessarily identify this as the same person. 

Other information
MAR_DUAL.  Rounds 1 and 2 contain a fourth monthly array.  If there is an overlap of partners (e.g., partner 1 leaves at the beginning of the month and partner 2 moves in at the end of the month), this array records the presence of the new partner.  The format of these variables is the same as the MAR_COHABITATION variables.  Beginning in round 3, this array was changed.  Because this is a relatively rare event, there is only one variable per round that indicates whether there was any month with an overlap period between the current interview and the previous interview.

Denial of previous data.  Occasionally, respondents report that the marital status information from a previous round is not true.  As is the case with employment, the information in arrays based on that rounds' information is maintained, but the respondent is assigned a value in a flag variable (MAR_DENY) indicating later denial of the information.  This flag variable has several different possible values, depending on the type of information denied.  For example, assume a respondent reported cohabiting at the round 2 interview date but denied that the cohabitation had occurred in round 3.  The status variables for each month from the beginning of the cohabitation to the round 2 interview date would continue to reflect the cohabitation, but the MAR_DENY variable would have a value of 3, indicating that the cohabitation was later denied.

Return to top

Program Participation Event History Arrays

Program participation arrays are constructed individually for five programs--Worker's Compensation, Unemployment Insurance, AFDC, Food Stamps, and WIC.  The AFDC array includes all federal and state programs created under Temporary Assistance to Needy Families (TANF) or any government program for needy families that replaces AFDC.  All other programs (e.g., LIHEAP, SSI, other) are combined into a sixth array entitled ‘Other.'  For each program type, except Worker's and Unemployment Compensation, three arrays are created.  All program participation arrays provide information starting in the month that the respondent turned 14 and ending in the month that he or she was last interviewed.

A secondary set of variables translates the reported beginning and ending dates (month and year) of a spell within the program into the continuous month scheme (e.g., AFDC_START_MONTH and AFDC_STOP_MONTH).  More information about the continuous month scheme is provided in Appendix 7 in this document.

1.  STATUS
The main array, (e.g., AFDC_STATUS), presents the status--receiving or not--of a respondent during each month.  When asked for the start or stop date of a spell, the respondent could answer ‘don't know' or ‘refuse' to any component.  In this case, the respondent was then asked how many weeks the spell lasted.  The number of reported weeks was then divided by 4.3 to determine the equivalent number of months.  If a fraction of a month was reported, then the entire month was counted as a month receiving benefits.  Using a combination of start date, stop date, and week information, each spell was defined and a value of ‘1' inserted into the status array to indicate months of receipt.  The months that a respondent did not receive that benefit, but was eligible to receive it, have a value of ‘0.'  An edit variable (e.g., AFDC_EDIT_DATE) flags respondent-reported and imputed dates.  The process by which imputed dates and the corresponding edit flag were assigned is described below:

2.  AMOUNT RECEIVED
If a respondent reports receiving in a particular month, a second array presents the amount received in each month (e.g., AFDC_AMT).  The dollar values asked about during the interview were meant to be monthly values.  However, some responses were higher than the federal or state limits on the amount received from a particular benefit.  A likely reason is that the respondent mistakenly reported a total value rather than a monthly value.  Values determined to be too high were divided by the number of months the respondent reported receiving the benefit.  These values were used in the AMT arrays instead.  A second set of edit variables (e.g., AFDC_EDIT_AMT) flags these values for a particular spell.  In round 1, the edit values were set for the latest year available. 

3.  HOUSEHOLD MEMBERS RECEIVING
If a respondent reports receiving in a particular month, the persons in the household who benefit from the program in each month (e.g., respondent only, child only, respondent and child) are recorded in a third array (e.g., AFDC_HH).  This program condenses the set of answers from the question in the survey that collects this information; for example, see YPRG-18300.01_001 to YPRG-18300.01_005 for AFDC.  Users should note that this array is not present for Worker's Compensation and Unemployment Insurance because these programs are collected for the respondent only.

Other information
A few respondents report receiving assistance but then deny that receipt in a later interview.  These situations are treated in the same way as in the marriage arrays, as described above.  The denial flag variables for the program participation arrays incorporate the name of the program (e.g., AFDC_DENY).

Researchers should be aware of an important source of variability in the Worker's Compensation data.  These data suggest that some respondents report the dates the payment was actually received and some report the period of time to which the payment applied.  For example, if a respondent was out of work for six months but received a lump sum payment a year later, he or she might report either the date the lump sum was paid or the dates he or she was unable to work.

Return to top

Schooling Event History Arrays

These education arrays are somewhat different than the other event history arrays.  Information on a respondent's education is reported in both yearly and monthly variables.  This approach is used to combine information from the youth questionnaire, which collects more detailed data, and from the round 1 parent questionnaire, which presented information only for each year.  Users should be aware that, because questions were not identical in the round 1 parent questionnaire and the round 2 youth questionnaire, the transition between the two data sources was not seamless and some information for the yearly variables had to be imputed.  If they feel that a given value is questionable, researchers may wish to compare created yearly variables to the raw data and to the monthly schooling arrays described below.

Yearly Schooling Variables:  A set of schooling variables provides information for each year beginning in 1980, the year when the first information is available in the survey, through the most recent interview year.  In general, these variables refer to the school year rather than the calendar year.  That is, 1991 in a variable title or in the data for a variable generally indicates the school year starting in fall 1991 and ending in spring 1992. 

1.  SCH_YEAR_to_GRADE
This array presents the grade the respondent attended during the school year.  The last four digits of the question name indicate the school year.  For example, SCH_YEAR_to_GRADE.1990 refers to the grade attended by the respondent during the school year that starts in fall 1990 and ends in spring 1991.

2.  SCH_GRADE_to_YEAR
This array refers to the year the respondent attended a certain grade.  For example, if the respondent attended second grade in 1992-93, then SCH_GRADE_to_YEAR.2 would have the value 1992.

3.  SCH_CHANGES
This array counts the number of times the respondent changed the school attended during the school year.  For example, SCH_CHANGES.1990 shows how many different schools the respondent attended during the school year that started in fall 1990 and ended in spring 1991.

4.  SCH_MNTHS_MISSED
This array presents the number of months during the school year that the respondent did not attend school.  For example, if SCH_MNTHS_MISSED.1990 has a value of 3 for a respondent, then that respondent had a gap in attendance of three months during the school year that started in the fall of 1990 and ended in the spring of 1991.  A gap is defined as missing school for one or more months (not including summer vacation); gaps do not have to be consecutive.

5.  SCH_SUMMER_SCHOOL
This array refers to extra school classes during an educational break in a given school year, such as summer school.  For example, SCH_SUMMER_SCHOOL.1990 shows whether the respondent attended school during a break in the 1990-91 school year.

6.  SCH_GRADE_PROGRESS
This array has positive values if there are any special events that occurred during the school grade.  For example, a positive value in SCH_GRADE_PROGRESS.2 indicates that the respondent was skipped or demoted during second grade.  Researchers should note that parents might have been confused as to how to answer the skip grade questions asked during the interview.  For example, there are parents who say their child skipped from 5th to 6th grade, while others say from 4th to 6th grades.  Both of these cases are probably stating that the child missed most or all of the 5th grade.  To resolve this ambiguity, the code states that if a child is skipped consecutive years then the first year (i.e. 5th grade) was missed. If a parent reports non-consecutive years (i.e. 4th to 6th) then the program assumes the year(s) in the middle are the ones not attended.

7.  SCH_YEAR_PROGRESS
This array refers to any special events that occurred during the school year.  The question name's last four digits indicate the school year this variable refers to.  For example, SCH_YEAR_PROGRESS.1990 shows special events that occurred during the school year that starts in fall 1990 and ends in spring 1991.  The special events, such as grades skipped or demoted to, are defined in the same way as in the previous array.

8.  SCH_SUSPENSIONS
This array counts the number of days during the school year the respondent was suspended from school.  For example, if SCH_SUSPENSIONS.1990 has a value of 3 then the respondent was suspended from school 3 days during the school year that started in fall 1990 and ended in spring 1991.

Monthly Schooling Variables.  In rounds 2-5, three types of monthly arrays and one flag variable (SCH_DUAL) were created.  Each array captures information for each month from the respondent's interview date in round 1 to the most recent interview date.

1.  SCH_STATUS
This array reports the respondent's enrollment status during each month from the round 1 interview date through the current interview date.  Coding categories include unknown, not enrolled, in grades K to 12, in college, on vacation, expelled, and other.

2.  SCH_TERM
These variables report the respondent's school type and grade for each month in the time period.  The first two digits represent the type of school (public = 10, private = 20, and religious = 30).  The last two digits provide the respondent's grade in school (1-12) or year in college (1-8).  To determine whether the school is a K-12 school or a college, researchers are advised to combine this variable with the SCH_STATUS variable described above.

3.  SCH_ID
This variable permits users to link array information to the school roster in the main data file and access other information about the school.  The variable uses the same ID codes as the identification variable on the school roster in the main data set (for example, NEWSCHOOL_PUBID.01).

4.  SCH_DUAL
A small number of NLSY97 respondents went to two different schools in the same month.  Because only the first school can be reported in the other arrays, this variable flags these special cases.  There is only one variable for the period between each round (that is, round 1 to round 2, round 2 to round 3, etc.); the exact month when the overlap occurred is not indicated, and overlap may have occurred in more than one month.

Return to top Return to Table of Contents