Question about WT06 - Unable to replicate published population statistics using ATUS-X

As preparation for using ATUS-X to generate time use estimates, I am trying to first replicate basic information on the size of the civilian population and the number of eldercare providers by age and sex, from published BLS tables: https://www.bls.gov/news.release/elcare.t01.htm. My estimates don’t match, and I believe that my problem lies in the weights. I downloaded an ATUS-X extract from the respondant-level files for sample years 2015 and 2016. My raw number of observations is 21,398 which is consistent with the number of observations reported in the technical note for this release. Based on exploring the data and reading other Q&As in this forum, I determined that, in order to obtain a person-weight that makes each CASEID represents a single-year individual, I must divide WT06 by 365.25. In order to obtain person-weights that generate 2-year annual average data, I divided WT06 by 730.5 (365.25 X 2). Using this 2-year average person weight (WT2YR= WT06/730.5), I obtain population estimates that are close, but not quite close enough, to the published data. For example, my estimated population size for the adult civilian population over the 2-year period is 256,562 thousand; the news release reportes 256,387 thousand. I estimate the number of eldercare providers as 41,352 thousand; the news release reports 41,324. I expected to be able to replicate the published tables to the thosands place. Can you tell me if I am using the correct weight, and if I am adjusting it correctly? (WT06/365.25 for annual population estimates; WT06/730.5 for 2-year annual average estimates.)

It looks like you are using a reasonable method to integrate the replicate person weight. In general, however, we don’t really expect to exactly replicate official statistics published by the BLS. This is because the official statistics are calculated using restricted access data that has a bit more detail than the public use data available via IPUMS. We do expect to get close, and within some margin of error, but not exact matches. It looks like this is the case with the estimates you’ve described above.