Summary
The fiscal year start and end date in migrated records are one day early.
Discovered: 2024-03
Timeline to repair: TBD
Github issue: TBD
Curation challenge
- Our server records time in GMT.
- We treat all submissions as if they were in SST (Samoa Standard Time)
What this means is that when someone submits data to the FAC, we look at the timestamp (in GMT), and subtract 11 hours (because we pretend the submission is coming from American Samoa). We do this to make sure that submissions from everywhere that might submit a Single Audit is considered "on time" as long as the grantee completes the submission on or before the day it is due.
This transformation makes sense for new submissions to the GSA FAC. It did not make sense for data we were migrating from Census. Because we subtracted 11 hours from every acceptance date coming from Census, it had the effect of moving those dates back one day.
The source of the error can be found in sac_creation.py
in the code.
Example
Any record migrated from Census will demonstrate this issue. For example:
Report ID |
Entity | Incorrect date | Correct date |
---|---|---|---|
2022-06-CENSUS-0000212928 | Gulf of Maine Research Institute | Dec. 27, 2022 | Dec. 28, 2022 |
2022-06-CENSUS-0000091651 | Berea College | Nov. 22, 2022 | Nov. 23, 2022 |
2022-06-CENSUS-0000211679 | Franklin W. Olin College of Engineering, Inc. | Nov. 16, 2022 | Nov. 17, 2022 |
Consequences
This impacts searches for audits in past years when using the acceptance date as a criterion. An audit that was submitted one day late will now appear on-time.
Mediating the error
End users can read fiscal year dates as one more than they are.
Possible resolution
Update the records containing incorrect dates, and re-disseminate the record. This will yield correct data in the public-facing tables.