MUR L4 GHRSST — filename date vs clicked day mismatch, which is correct?
MUR L4 GHRSST — filename date vs clicked day mismatch, which is correct?
I noticed that when browsing the CMR virtual directory for the MUR L4 GHRSST collection (https://cmr.earthdata.nasa.gov/virtual-directory/collections/C1996881146-POCLOUD) and clicking a given calendar day, the granule returned is dated one day later than the day clicked. For example, clicking 5 March 2022 returns 20220306090000-JPL-L4_GHRSST-SSTfnd-MUR-GLOB-v02.0-fv04.1, and clicking 6 March returns the 7 March granule.
I saw a thread from 2024 where User Services confirmed the same behavior, and it seems to still be happening in 2026.
Could you confirm: is the filename date the correct/authoritative date for that granule's SST field, and should we be matching files to calendar dates using the filename rather than the day we clicked to reach it? Just wanted to make sure we're pulling the right day's SSTs.
Thanks!
I saw a thread from 2024 where User Services confirmed the same behavior, and it seems to still be happening in 2026.
Could you confirm: is the filename date the correct/authoritative date for that granule's SST field, and should we be matching files to calendar dates using the filename rather than the day we clicked to reach it? Just wanted to make sure we're pulling the right day's SSTs.
Thanks!
Last edited by zperry on Mon Aug 24, 2026 11:54 am America/New_York, edited 1 time in total.
Filters:
-
PODAAC - edward.m.armstrong
- Subject Matter Expert

- Posts: 33
- Joined: Thu May 27, 2021 2:52 pm America/New_York
-
PODAAC - edward.m.armstrong
- Subject Matter Expert

- Posts: 33
- Joined: Thu May 27, 2021 2:52 pm America/New_York
Re: MUR L4 GHRSST — filename date vs clicked day mismatch, which is correct?
Hi zperry
Sorry for the late reply.
The reason you are seeing this is that the MUR processing system takes data from 9PM to 9AM the next day (nighttime SST info). The majority of the data in the fusion algorithm is from after midnight so the filename date stamp reflects this. The ingest system works off the internal metadata time_coverage_start (9AM) that places the file in a virtual daily folder one day before.
Bottom line is use the filename date as representative of the MUR SST period.
Hope this helps.
regards,
Ed Armstrong, PO.DAAC
Sorry for the late reply.
The reason you are seeing this is that the MUR processing system takes data from 9PM to 9AM the next day (nighttime SST info). The majority of the data in the fusion algorithm is from after midnight so the filename date stamp reflects this. The ingest system works off the internal metadata time_coverage_start (9AM) that places the file in a virtual daily folder one day before.
Bottom line is use the filename date as representative of the MUR SST period.
Hope this helps.
regards,
Ed Armstrong, PO.DAAC