Repository navigation
Collection date times not matching with granules #296
Description
Describe the bug
At the collection level, pyQuARC was not flagging temporal extents that did not match with the granules.
Example
UMM-C Record: C2066317191-LARC
Expected behavior
pyQuARC should flag the Beginning and Ending Date Times.
For the beginning date time, 2017-06-01T00:00:00.000Z was provided at the collection level, but the granule is 2017-06-01T01:10:32Z.
For the ending date time, 2023-01-31T00:00:00.000Z was provided at the collection level, but the granule is 2023-01-29T15:48:31Z.
Activity
lavanya3k commentedon Apr 17, 2025
Describe the bug (testing): As per the previous fix on the collection datetime on the TemporalExtents/RangeDateTimes/BeginningDateTime and TemporalExtents/RangeDateTimes/EndingDateTime on collection, the collection datetime is matched with the granule begin datetime and end datetime. However, the bug is not completely resolved. The datetime field need to have 'T' and 'Z' suffix for the date and timestamp as '2012-10-14T00:00:00Z'.
Example:
C2066317191-LARC --format umm-c
C1000000023-CDDIS --format umm-c
C1000000044-CDDIS --format umm-c
Expected outcome (update):
#296 Collection date not matching with granules bugs fixes
lavanya3k commentedon May 9, 2025
PR update #299
FBayat021 commentedon Jul 31, 2025
FYI: the initial record
C2066317191-LARChas converted to the followingC3525232241-LARC_CLOUD(version 6).Please address before pushing PR to the Dev/Master branch:
FB: If the time difference is more than 24 hours, the output message should be an "Error" (red) and not a "Warning" (yellow)
FB: Please change the output message to the following:
"Note: The collection beginning date time 'COLLECTION DATETIME' is not consistent with the beginning date time in the metadata for the first granule in Earthdata Search 'GRANULE DATETIME'. Recommend updating the beginning date time to match the granule extent."