A newly updated catalogue can still describe an old observation
You search an imagery catalogue for observations made during a storm. Several results were updated this morning, so they look reassuringly current. But an update can describe the catalogue record rather than the observation. Before interpreting the images, you need to know which clock each timestamp belongs to.
The SpatioTemporal Asset Catalog, or STAC, provides fields for searchable time and capture intervals. This guide explains how to read those fields, compare them with a research window and preserve their meaning when data moves into a spreadsheet, dashboard or report. The central question is simple: when was the relevant evidence actually acquired?
All Items, dates, quantities and selection results in the worked exercises are fictional. They illustrate reasoning, not the behaviour of an unnamed live service. Real products can add temporal rules through their documentation and extensions; a catalogue match alone does not establish continuous observation or scientific suitability.
Geoinformatics subject guide · Learning that transfers into life · How X Works hub
Choose your reading route
Route 1: Identify the clock · Chapters 1–3
Route 2: Compare time windows · Chapters 4–6
Route 3: Protect analytical meaning · Chapters 7–8
Route 4: Test and transfer · Chapters 9–10
Route 5: Review and hand off · Chapters 11–12
Full chapter index · Independent worked case · Questions and practical checks
Chapter index
Identify the clock · Chapters 1–3
Separate observation time from record maintenance
Read the searchable datetime with its product meaning
Keep interval bounds and null values explicit
Compare time windows · Chapters 4–6
Normalise instants before comparing calendar dates
Distinguish overlap, containment and representative-time selection
Handle shared endpoints without accidental double counting
Protect analytical meaning · Chapters 7–8
Do not confuse a capture range with continuous coverage
Avoid unsupported duration weighting and independence claims
Test and transfer · Chapters 9–10
Test metadata updates without pretending the scene changed
Transfer the model into tables and human-readable reports
Review and hand off · Chapters 11–12
Use a small adversarial temporal fixture
Hand off the time question, not just the timestamp
CHAPTER 1 OF 12
1. Separate observation time from record maintenance
Imagine a photograph taken on Monday, described in a catalogue on Wednesday and corrected on Friday. Those three events can all have accurate timestamps. None needs to be an error. The error begins when a reader takes Friday’s correction time as proof that the camera observed the scene on Friday. A date becomes evidence only after its event has been identified.
Start a temporal ledger with separate rows for acquisition, processing, metadata creation, metadata update and retrieval. Not every dataset supplies every row, and some products need additional clocks. Leave unsupported entries unknown. Do not fill an absent acquisition date with the download time merely because the application insists on showing a date beside every result.
Consider a fictional archive photograph acquired on 1 October and catalogued on 20 October. Correcting its title on 30 October improves the description without refreshing the photographed scene. A current description of historical evidence is useful, but it answers a different question from a current observation. Both the catalogue and the report should preserve that distinction.
Ask what changed before reacting to an update. Was the underlying asset replaced, the processing revised, a footprint corrected or only a description edited? The timestamp alone rarely supplies the full change history. Link the interpretation to the relevant object and provider documentation rather than treating every field containing the word time as interchangeable.
CHAPTER 2 OF 12
2. Read the searchable datetime with its product meaning
STAC’s Item datetime is a searchable timestamp for the assets. It is often an acquisition time for a single capture, but it can be a representative time for combined assets. The specification allows datetime to be null when an interval is supplied instead. A populated field therefore deserves interpretation, not an automatic assumption that every value inside every asset was observed at that instant.
Imagine a fictional composite assembled from several days of imagery. A nominal middle date can help discovery while concealing the spread of contributing observations if you read it alone. The number is not necessarily false; it may be a deliberately compact representation. What matters is whether that representation is sufficient for the question you are trying to answer.
For a school exercise, label three cards single capture, composite and time series. Give each the same representative timestamp. Then ask which card supports a claim about the scene at exactly that time. The answer depends on how the product was made, not on whether its JSON timestamp passes a formatting check. Structural validity and temporal interpretation remain separate tests.
Read the product’s temporal definition before combining Items from different collections. Two providers can use searchable dates in different documented ways. A sorting operation can place their records on one timeline without making their observations directly comparable. Preserve those differences in the analysis plan instead of losing them during the first export.
CHAPTER 3 OF 12
3. Keep interval bounds and null values explicit
The STAC common metadata start_datetime and end_datetime fields describe inclusive capture bounds. When either is supplied, the other is required; they are also required when Item datetime is null. A non-null datetime can coexist with an interval. These rules make room for both a convenient representative time and the wider temporal support needed to interpret a combined resource.
Picture a fictional Item whose contributing observations extend from 10:00 to 12:00 UTC. Its bounds tell you that the capture range reaches both endpoints. They do not, by themselves, prove that a sensor measured every second between them. A bounding interval can enclose gaps just as a geographic rectangle can enclose places with no observations.
Do not turn JSON null into midnight, an empty string or today’s date during a spreadsheet import. Each replacement adds an unsupported temporal assertion. Retain the interval and the reason for the missing representative instant where documentation supplies one. If a receiving application cannot preserve the model, document the loss or choose a more suitable exchange route.
Likewise, a lone start bound is not an invitation to invent an end. It may indicate a malformed record under the applicable rule. Report the validation issue separately from the analytical uncertainty. A technically incomplete record and a valid broad interval are different problems, even when both prevent the particular comparison you hoped to make.
CHAPTER 4 OF 12
4. Normalise instants before comparing calendar dates
An instant can be written with different local clock readings. In a fictional example, 31 October at 00:15 with an offset of plus eight hours corresponds to 30 October at 16:15 UTC. The calendar day changes during conversion, while the instant does not. Comparing the visible date characters before interpreting the offset can therefore select the wrong day.
STAC timestamps are expressed in UTC. When preparing local observations for that contract, use a proper time-aware conversion and retain the original source representation in the processing evidence. Do not remove the offset text while leaving the local clock unchanged. That operation relabels a number; it does not convert the instant represented by the number.
For a paper test, write the local instant and the UTC instant on opposite sides of one card. Search for the UTC day 30 October. Both sides must lead to the same inclusion decision after interpretation. A system that includes one but excludes the other is responding to formatting rather than the underlying temporal relationship.
Avoid claiming that every local zone has a permanently fixed offset. Our plus-eight fixture is an explicit arithmetic example, not a universal timezone algorithm. Real source records may need named-zone rules, historical context and handling of ambiguous local times. A missing offset should remain a question to resolve, not a number to guess from the analyst’s current location.
CHAPTER 5 OF 12
5. Distinguish overlap, containment and representative-time selection
Suppose your fictional research window runs from 10:00 to 12:00 UTC. An Item captured from 09:00 to 10:15 overlaps that window but is not contained within it. Another captured from 11:45 to 12:15 also overlaps without being contained. A question asking for any intersecting capture periods is different from one asking for wholly internal observations.
For closed intervals, the paper overlap test is start at or before the window end, and end at or after the window start. Containment instead requires the Item’s start at or after the window start and its end at or before the window end. These formulas are definitions for our exercise. Verify a real service’s advertised temporal-query contract before assuming it implements the same selection.
Now give the first Item a nominal datetime of 09:30. Selecting only representative instants between 10:00 and 12:00 excludes it, although its capture interval overlaps. That outcome may be correct for a representative-time question and inadequate for an overlap question. A useful report names the selection rule rather than merely saying the data was filtered by date.
Compare the resulting IDs as well as the total. Two incorrect filters can each return three Items while selecting different observations. A count is a coarse consistency check, not a full test of temporal meaning. Keep a small fixture with known inside, outside, overlapping and boundary cases so that the intended relation can be tested independently.
CHAPTER 6 OF 12
6. Handle shared endpoints without accidental double counting
Inclusive capture bounds do not force every later analytical time bin to use inclusive endpoints. Suppose a dashboard uses adjacent hourly bins. If both bins include their common endpoint, an instantaneous observation exactly at 11:00 can enter both. That may be intended for some summaries, but it is not a neutral consequence that should pass unnoticed.
A common analytical design is a half-open bin: include its start and exclude its end. Under that declared rule, the instant 11:00 belongs to the bin starting at 11:00, not the bin ending there. This is a choice for the downstream calculation, not a claim that STAC’s inclusive capture bounds have changed. Keep the two conventions separate.
Try three fictional observations at 10:59, 11:00 and 11:01. The first bin, 10:00 through just before 11:00, contains one. The next, 11:00 through just before 12:00, contains two. A closed-both-ends implementation would count the boundary instant twice across those bins. The combined total reveals the allocation problem.
Intervals require another decision: are you counting Items that intersect each bin, allocating duration or estimating an underlying quantity? One long Item can legitimately intersect several bins without representing several independent captures. Explain which unit is being counted. Item-bin relationships and distinct Item identities should not be added together as though they were the same population.
CHAPTER 7 OF 12
7. Do not confuse a capture range with continuous coverage
A collection may have a broad advertised temporal extent, while its individual Items occupy scattered periods. An individual composite can also have broad capture bounds with only a few contributing observations. In both cases, the enclosing interval is useful for discovery but insufficient to prove uninterrupted monitoring. A gap does not become an observation because it lies between two dates.
Imagine measurements at 10:00, 10:05 and 11:55. Their enclosing range lasts 115 minutes, yet the middle of that range has no listed measurement. A claim that the instrument continuously watched the scene for 115 minutes would require additional evidence about the acquisition process. The three timestamps alone do not establish it.
For a changed-context check, replace imagery with a weather log containing a few manual entries. The start and end of the notebook do not prove that somebody observed every intervening hour. The transferable reasoning is about support: identify the periods or instants for which evidence exists and distinguish them from the range used to summarise that evidence.
Report temporal completeness with a declared expected schedule when the task needs one. If ten expected hourly observations yield seven usable observations, that is a different statement from seven Items intersecting a ten-hour window. Multiple Items may describe the same hour, and one Item may span several hours. Reconcile the expected support rather than substituting a convenient file count.
CHAPTER 8 OF 12
8. Avoid unsupported duration weighting and independence claims
Two fictional composites cover 18:00–20:00 and 19:00–21:00. Each has a two-hour capture range, but their union lasts three hours, not four. Adding interval lengths counts their shared hour twice. Whether that duplication matters depends on the calculation, but a claim of four distinct hours of coverage is already unsupported.
Suppose their reported values are 10 and 20. The simple Item average is 15. Weighting each by its two-hour bounding duration also gives 15, but this numerical agreement does not establish a time-average of the real scene. You still need to know what the values summarise, how contributing observations were weighted and what happened during the overlap.
Do not assume overlapping Items are independent measurements. They may reuse source observations or differ only by processing version. A large count of downloaded assets can therefore overstate the amount of independent evidence. Preserve source lineage and product identifiers where available, and state when the dependence structure cannot be established from the catalogue alone.
The useful stopping point is specific: we have two available products with these documented temporal supports, but cannot infer a continuous three-hour mean without further product evidence. That is not a failure to calculate. It is the correct boundary between a justified summary of available Items and an unsupported claim about an underlying physical process.
CHAPTER 9 OF 12
9. Test metadata updates without pretending the scene changed
STAC created and updated values have meanings tied to their placement. At Item metadata level they concern the metadata entity; on an Asset they concern the linked resource. Inspect the object carrying the field. Copying a date into a flat column named updated can erase the distinction between record maintenance and changes to the data being described.
Make a fictional test with one acquisition on 1 October, an Item created on 3 October and its description corrected on 30 October. An observation-date search should not silently move that acquisition into a late-October event study merely because the metadata changed. A maintenance queue may legitimately use the update time, but it is answering a different operational question.
Then replace the underlying asset with a newly processed version of the same source observation. The scene date can remain 1 October while the processing and resource history change. A reproducible analysis should identify the actual version used. Retaining only the observation date is insufficient when processing revisions can change the returned values.
Build separate tests for date selection and version selection. One checks whether the correct observation periods were chosen; the other checks which resource edition supplied the calculation. Passing either test alone does not establish that an earlier published result can be reproduced. Keep both clocks attached to their respective objects in the final evidence record.
CHAPTER 10 OF 12
10. Transfer the model into tables and human-readable reports
A spreadsheet can preserve temporal meaning if its columns remain explicit. Use separate fields for observation instant, capture start, capture end, metadata update and resource version where those facts are known. Include timezone interpretation and the chosen query relation. A single date column may be convenient, but it can make a complex product impossible to interpret correctly later.
A human-readable report need not display every technical field. It should still make its main statement honest. For example: these four Items intersect the study window, two extend beyond it, and their temporal bounds do not establish continuous coverage. That sentence tells the reader substantially more than four recent images were found.
For transfer practice, give a colleague the exported table without your map or search interface. Ask them to recover the selected IDs under the declared rule. If they need to guess whether dates represent acquisition or update, the handoff is incomplete. Fix the column meanings rather than adding another reassuring sentence to the conclusion.
Preserve the original catalogue record or a versioned source snapshot when permitted. Later provider corrections can change dates or resource links. A current live catalogue can be useful for ongoing discovery without being the exact input used by an earlier analysis. Record retrieval time separately so that the difference remains inspectable.
CHAPTER 11 OF 12
11. Use a small adversarial temporal fixture
A practical test set should contain an instant strictly inside the window, one strictly outside, an interval crossing each boundary, an exact endpoint and a valid interval with no representative instant. Add a metadata-only update and two representations of the same instant during source normalisation. Each case isolates a different failure mode that a large random sample may miss.
Write the expected IDs before running the client. Otherwise it is easy to accept whatever the interface returns and unconsciously redefine the intended question around it. For each discrepancy, ask whether the cause is malformed metadata, wrong timezone interpretation, a different selection relation, a client limitation or undocumented service behaviour. Do not call every mismatch bad imagery.
Retain returned metadata and the actual selection request. A screenshot of four thumbnails proves very little about which temporal relation was applied. The evidence should allow another person to distinguish a correctly interpreted empty result from a failed request or a query against the wrong clock. Those outcomes need different explanations and different repairs.
Keep the fixture small enough to calculate by hand and realistic enough to expose the intended mistake. The goal is not to simulate every possible product. It is to establish a trusted baseline, then add documented product-specific tests where the actual research task needs them. A precise, bounded result is more useful than an unsupported claim of universal temporal correctness.
CHAPTER 12 OF 12
12. Hand off the time question, not just the timestamp
A complete temporal handoff states the research window, time basis, selection relation, product date definitions, source versions, unresolved gaps and downstream binning rule. It identifies what changed during any correction. If the only note says dates fixed, a recipient cannot tell whether an offset was converted, metadata was repaired or the underlying observation period was reinterpreted.
Ask the final reader to explain one included boundary Item and one excluded Item in ordinary language. The explanation should connect the actual times to the stated question. This is a transfer check: the reader must be able to apply the relationship to a new Item, not merely repeat the IDs in the earlier worked example.
Also state what the evidence cannot establish. Temporal overlap does not guarantee cloud-free imagery, correct calibration, spatial coverage or an independent observation. Those checks belong to the relevant asset and quality guides. Time is one part of the evidence chain, and its successful interpretation should not be expanded into a claim that every other dependency has passed.
The practical endpoint is a timeline whose labels can be defended. You can say when observations were made, which intervals they represent, what was updated later and why the selected products answer the intended date question. That clarity survives a change of interface because it depends on explicit relationships rather than the appearance of a search result.
Independent worked case and evidence checks
Try this independent fictional catalogue. The study window is the closed interval 10:00–12:00 UTC on 30 October. Item A is an instant at 10:30. B has capture bounds 09:00–10:15. C has bounds 11:45–12:15. D was observed the previous day but its metadata was updated at 11:00 on the study day. E is an instant at exactly 12:00.
Under the exercise’s declared overlap rule, A, B, C and E qualify. D does not qualify merely because of its update. There are four selected Item identities. Under complete containment, A and E qualify, while B and C extend outside the window. Under a different half-open instant-only bin, the endpoint treatment would change; that is why the rule must accompany the count.
Now suppose B’s representative datetime is 09:30 and C’s is 12:05. A filter looking only at representative instants would exclude both. It would return a different set from the interval-overlap test. Neither set should be labelled the universal correct answer without naming the question and verifying the applicable service behaviour.
Does selecting four Items establish two hours of continuous observation? No. A and E are instants. B reaches only to 10:15, and C starts at 11:45. The catalogue facts listed here do not establish support throughout the middle period. Even B and C’s interval bounds do not prove continuous acquisition inside their own ranges.
Change the source representation of A to a local time with a plus-eight offset: 18:30 on 30 October. Conversion gives the same 10:30 UTC instant. A client that drops the offset without conversion moves A eight hours later and can incorrectly exclude it. The control is the instant, not the visible clock string.
Next add F at 00:15 on 31 October with a plus-eight offset in the incoming source log. Its UTC instant is 16:15 on 30 October. F is outside our two-hour window but inside the UTC calendar day 30 October. This checks two decisions at once: timezone conversion and the difference between a day query and a narrower study window.
Finally correct D’s metadata again tomorrow without changing its observation date. The selected observation population should remain unchanged under the same source facts and rule. If it changes, inspect whether the application has accidentally substituted a maintenance clock for the observation clock. Record the correction and the test result so a later reviewer can reproduce the decision.
Worked comparison
| Question | Evidence to inspect | What the result does not establish |
|---|---|---|
| When was it observed? | Documented datetime and capture bounds | Metadata update time is not a substitute |
| Does it intersect the study window? | Declared overlap relation | Full containment or continuous coverage |
| Which clock is being updated? | Field location and resource history | A newly observed scene |
| How much time is covered? | Union of justified temporal support | Sum of overlapping Item durations |
| Can the analysis be repeated? | Catalogue snapshot and actual asset version | A date label alone |
Questions and practical checks
Does updated mean the image was captured again?
Not automatically. Identify whether the field concerns Item metadata or a linked Asset, then inspect what actually changed.
Can datetime be null?
STAC allows it when the required start and end capture fields supply an interval. Do not replace that null with an invented instant.
Are capture bounds exclusive?
STAC common metadata describes inclusive start and end bounds. A downstream analytical bin can use another explicitly declared convention without rewriting that meaning.
Does an interval prove continuous measurements?
No. It can enclose gaps or summarise combined observations. Check the product’s actual temporal support.
Can one time filter work for every product?
Only if its intended relation and the products’ temporal meanings genuinely match. Test representative instants, intervals, boundaries and source timezone conversion.
Continue with the connected subjects
Read catalogue evidence before analysis
STAC asset roles: choosing resources that actually support the task
STAC catalogue language: preserve identifiers and underlying asset meaning
Keep other completeness checks separate
Raster validity masks: usable measurements and coverage denominators
GeoJSON record completeness: existence, supplied location and display
Sources and scope
OGC STAC1.1: Item datetime, common capture bounds and entity-specific update fields
RFC3339: timestamps, UTC offsets and interoperable date-time representation
The numerical cases in this guide are original fictional teaching examples, not measurements from a real site. This is an educational explanation, not a field safety instruction, engineering approval or an official certification. For a real project, use qualified practitioners, current product documentation and site-specific evidence. Sources were checked on 30 October 2026.
Connect the time, grid and file checks
These guides cover different dependencies in one geographic information chain. A successful result at one stage does not replace the evidence needed at another. Choose the check that matches the unresolved question.
Tile matrices: grid dimensions, pixel positions and stored coverage. Establish where image data belongs before using its numerical content or claiming full spatial coverage.
Foreign keys: orphan references and the limits of integrity checks. Check declared relationships and independently justified associations rather than relying on one healthy-file result.
Extension scope: operation-specific reading and editing support. Establish what the receiving reader or writer supports before treating a successful preview as complete interoperability.