Launch Watch · Analysis

Published 4 October 2026, 08:54 HST (UTC−10)

GOES file clocks: a 192-file audit of scan and archive timing

A 192-file GOES-16 audit shows why scan start, scan end, creation and archive modification produce different timing intervals.

A GOES-16 Band 13 file for 1 January 2024 carries a creation time just 7.6 seconds after its scan ends. Compare that same creation time with the scan’s start and the interval becomes 166.0 seconds. Both subtractions are correct. They describe different parts of the observation-to-file sequence.

We decoded all 192 filenames and archive modification timestamps in the NOAA GOES-16 public listing for ABI Level 1b CONUS radiance, day 001, hour 00. The listing contains 12 files for each of 16 bands and is not truncated. The 12 Band 13 files provide a compact worked example of how the clocks differ. This is a historical metadata audit, not a test of today’s delivery speed.

Four clocks in one real file

The first Band 13 object has this filename. NOAA’s file-naming guide identifies the observation-start, observation-end and file-creation fields. Its timestamps encode year, day of year and UTC time to a tenth of a second.

OR_ABI-L1b-RadC-M6C13_G16_s20240010001173_e20240010003557_c20240010004033.nc

The scan spans 158.4 seconds. Creation minus scan end is 7.6 seconds; creation minus scan start is 166.0 seconds. Using the start adds the entire scan duration. Likewise, LastModified minus scan end is 30.3 seconds, while LastModified minus scan start is 188.7 seconds. A latency value without its two clock definitions is therefore incomplete.

Method: repeat the subtraction across 12 scans

For each object, we parsed the three filename timestamps and the listing’s LastModified field, then subtracted the scan end from the other two clocks. We preserved the complete timestamp before computing differences; the chart shortens only the x-axis labels. Every selected band has 12 files, so the Band 13 sequence is the full band-specific set in this listing rather than a hand-picked selection of fast files.

The Band 13 scan spans range from 158.4 to 158.5 seconds. Creation follows scan end by 5.3–8.4 seconds, with a median of 7.3 seconds. The corresponding LastModified differences range from 17.2 to 36.2 seconds, with a median of 25.3 seconds. The different ranges show why file creation and archive modification should remain separate fields in an audit.

What the archive cannot establish

Amazon’s S3 metadata documentation defines Last-Modified as the later of object creation or modification. This saved listing does not tell us whether that timestamp corresponds to its first arrival or a later overwrite. Nor does it include a subscriber’s receipt log. Calling the 17.2–36.2-second range “end-to-end delivery latency” would add an observation that this audit did not make.

The filename also brackets a sector scan. It does not supply the exact acquisition time for an individual pixel in that scan. A launch plume appearing near one edge of a sector cannot automatically be assigned the file’s start or end time as its own acquisition instant.

Carry both endpoints into the next comparison

For a repeatable metadata audit, save the full listing, check whether it is truncated, keep the product and band selection explicit, and record the two clocks behind every subtraction. For actual delivery performance, add a separately recorded receipt timestamp. For a physical event in imagery, retrieve the timing information appropriate to that location and product.

The useful result here is narrow and reproducible: in this one-hour Band 13 sample, choosing scan start instead of scan end adds approximately 158 seconds to the reported interval. It does not make the archive slower. It changes the question being measured.