DPchecker (Data Package checker) is a package with a series of functions for NPS data package authors and reviewers to check for internal consistency among data/meta data and with the data package standards
Currently, test_date_range looks at ALL date columns within a data package. But, what if the data were collected on one date and verified or QC'd on another date. The temporal range specified in metadata should encompass the dates data were collected on, but the verification dates could fall outside that range. In it's current configuration, this would cause test_date_range to fail with an error.
Is this scenario the type of thing we would expect a human data package reviewer to sort out, our should we account for it programmatically? Incorporating this scenario might require adding the ability to exclude some custom columns (e.g. dateVerified) from the test_date_range function. If we go that route, it would be worth thinking about how to do this while still maintaining the relatively streamlined nature of DPchecker::run_congruence_tests.
Currently, test_date_range looks at ALL date columns within a data package. But, what if the data were collected on one date and verified or QC'd on another date. The temporal range specified in metadata should encompass the dates data were collected on, but the verification dates could fall outside that range. In it's current configuration, this would cause test_date_range to fail with an error.
Is this scenario the type of thing we would expect a human data package reviewer to sort out, our should we account for it programmatically? Incorporating this scenario might require adding the ability to exclude some custom columns (e.g. dateVerified) from the test_date_range function. If we go that route, it would be worth thinking about how to do this while still maintaining the relatively streamlined nature of DPchecker::run_congruence_tests.