Temporal query parameters (resultTime, phenomenonTime, datetime) silently ignored — all values discarded, including `latest`

[Sam-Bolling]

Issue evolution notice. This issue was originally filed as "resultTime=latest temporal filter not supported" based on the assumption the server rejected or errored on the latest keyword specifically. A subsequent empirical re-test against the live Go server (see the comment thread and below) showed the defect is broader and more silent than originally described: the entire temporal parameter parser is a no-op, not just the latest keyword. The body below has been rewritten to reflect the corrected diagnosis. The original filing is preserved verbatim in the collapsible section at the bottom for historical transparency; nothing is being hidden or retracted.

Finding

The Go CSAPI server accepts resultTime, phenomenonTime, and datetime query parameters on observation/datastream endpoints without error and without effect. Every value — valid ISO 8601 intervals, the latest keyword, far-future dates, and even obvious garbage — is silently discarded. The server returns its default unfiltered page in all cases. No 400, no 422, no warning, no log entry.

This is a conformance failure against OGC API — Connected Systems — Part 2: Dynamic Data (OGC 23-002r0), Clause 13.3.2, Requirement /req/advanced-filtering/obs-by-resulttime — not merely a missing latest keyword handler.

Review source: Live integration testing against the Go CSAPI server during the ISS map investigation, documented in CSAPI Go Server Integration Report §12–§13. Empirical re-test documented in the comments on this issue.

Severity: P2-Important (elevated from original P3-Minor — silent filter ignorance is a correctness hazard for any client relying on temporal slicing, not just latest).
Category: Standards Conformance.
Ownership: Upstream (SomethingCreativeStudios/connected-systems-go).

Normative requirement being violated

OGC 23-002r0, Clause 13.3.2 — Requirement /req/advanced-filtering/obs-by-resulttime:

A	The HTTP GET operation at an Observation resources endpoint SHALL support a parameter resultTime.
B	The parameter SHALL fulfill the same requirements as the parameter datetime defined in Clause 7.15.4 of OGC API — Features — Part 1: Core.
C	Only the resultTime property of Observation resources SHALL be used to determine the temporal extent evaluated against the parameter.
D	In addition to the possible parameter values defined in OGC API — Features — Part 1: Core, the parameter SHALL also support the special value latest. When this special value is used, only observations with the latest result time SHALL be included in the result set.

Parallel requirement for phenomenonTime at Clause 13.3.1 (/req/advanced-filtering/obs-by-phenomenontime) has the same A/B/C structure. Go fails A, B, C, and D.

• Conformance test IDs: /conf/advanced-filtering/obs-by-resulttime, /conf/advanced-filtering/obs-by-phenomenontime (both would fail against the current implementation).
• Draft URL: https://docs.ogc.org/DRAFTS/23-002r0.html (Clause 13.3.2)

Empirical evidence

Tested against production endpoint https://129-80-248-53.sslip.io/csapi-go on datastream db6756eb-e4ed-47e9-94c2-02eff5edf8d4 (ISS Position, 1000+ observations):

Request	Expected	Actual	Verdict
?resultTime=latest	1 observation (per spec D)	10 items (default page, unfiltered)	❌ silently ignored
?resultTime=latest&limit=1	1 observation (the latest)	1 item, the newest (works by accident — Go's descending default sort + limit=1 happens to yield the correct answer)	⚠️ coincidental correctness
?resultTime=2099-01-01T00:00:00Z/2099-12-31T23:59:59Z	0 items (no future data)	10 items from today (unfiltered default page)	❌ silently ignored
?resultTime=frobnicate	400 Bad Request (per OGC Features §7.15.4 / OAS validation)	200 OK, 10 items (unfiltered)	❌ garbage accepted
?resultTime=2024-01-01T00:00:00Z/2024-01-02T00:00:00Z	observations inside window	10 items from today (window ignored)	❌ silently ignored
?phenomenonTime=now	observations at now (per spec §13.3.1 example)	10 items from today (unfiltered)	❌ silently ignored

The server NEVER errors and NEVER returns an empty list. It always returns the default unfiltered page, regardless of parameter value. This is what makes the defect dangerous: downstream clients have no signal that their filter was ineffective.

Impact on consumers

Because the server silently discards all temporal filter values, any consumer relying on temporal filtering for correctness (not just for "latest") will:

• Process observations that are outside the requested time window, without knowing.
• Miss windowing/retention logic (e.g., "only process the last 5 minutes").
• Get correct-looking results from resultTime=latest&limit=1 today only because Go defaults to descending sort; a future change to the default sort order, or an addition of ascending support, would silently break every such consumer.

The CSAPI Explorer's MapViewPage.vue originally contained a 7-site fallback pattern (see ogc-client-CSAPI_2#168) that happened to mask this bug for the "latest observation" use case. That workaround is dead code today — the primary URL already returns data (because Go ignores latest but limit=1 survives) — and it does not protect against the range-filter case at all. The server bug is the actionable root cause.

Files to Modify

File	Change	Est. lines	Notes
internal/model/query_params/query_params.go (or temporal parser)	Modify	~40	Implement parsing for ISO 8601 instant, closed interval, half-open intervals (../, /..), and the special keywords latest and now. Reject unparseable values with 400.
internal/repository/observation_repository.go	Modify	~20	Apply parsed temporal bounds to SQL WHERE result_time … / WHERE phenomenon_time … clauses. For latest, emit ORDER BY result_time DESC LIMIT 1.
internal/handler/ (or equivalent)	Modify	~5	Return 400 with an OGC-style error body for malformed temporal values.
e2e/	Modify	~60	Add E2E tests per acceptance criteria below.

Proposed Solutions

Option A — Implement the full temporal parser correctly (Recommended)

Parse resultTime, phenomenonTime, and datetime values per OGC Features Part 1 §7.15.4, extended with the latest keyword for observations endpoints per OGC CS Part 2 §13.3.2 D. Apply as SQL range predicates; special-case latest as ORDER BY <timeCol> DESC LIMIT 1 merged with any other predicates/filters.

Pros: Fixes all four statements (A–D) of the requirement at once; matches SensorHub behavior; removes the need for any client-side workaround on any consumer.
Cons: Touches parser, validator, and repository.
Effort: Medium. Risk: Low (orthogonal to existing code paths; unparseable values currently produce no output anyway).

Option B — Keyword-only patch (NOT recommended)

Add a special case for the latest string only, leaving range parsing still broken.

Pros: Smallest possible diff.
Cons: Leaves statements A–C of /req/advanced-filtering/obs-by-resulttime unsatisfied; leaves phenomenonTime ranges and datetime on systems/deployments broken; leaves silent-discard-of-garbage intact. Will not pass /conf/advanced-filtering/obs-by-resulttime.
Effort: Small. Risk: High (false sense of compliance).

Scope — What NOT to Touch

• ❌ Do NOT limit the fix to the latest keyword — statements A–C require the full range parser to work.
• ❌ Do NOT change how other non-temporal query parameters are parsed unless they share the temporal parser path.
• ❌ Do NOT implement latest for non-observation resource types; it is defined only for observations endpoints per §13.3.2 D.
• ❌ Do NOT widen scope to uid=, subdeployments, or other unrelated filter bugs; they have their own issues.

Acceptance Criteria

1. GET /datastreams/{id}/observations?resultTime=latest → exactly the observation(s) with the maximum resultTime (spec §13.3.2 D).
2. GET /datastreams/{id}/observations?resultTime=2024-01-01T00:00:00Z/2024-01-02T00:00:00Z → only observations whose resultTime intersects that closed interval.
3. GET /datastreams/{id}/observations?resultTime=2024-01-01T00:00:00Z/.. → only observations at or after the instant (half-open interval).
4. GET /datastreams/{id}/observations?resultTime=../2024-01-01T00:00:00Z → only observations at or before the instant.
5. GET /datastreams/{id}/observations?resultTime=frobnicate → HTTP 400 with an OGC-style error body; no 200-with-default-page.
6. Equivalent behavior for phenomenonTime on observations endpoints per §13.3.1 (A/B/C; no latest keyword required for phenomenonTime).
7. Equivalent behavior for datetime on systems/deployments/samplingFeatures endpoints per OGC 23-001r0 §8.7.
8. The abstract test /conf/advanced-filtering/obs-by-resulttime passes (the test issues a bounded resultTime query and verifies every returned observation's resultTime falls inside the window).
9. Existing tests still pass (make test).
10. E2E test added for each of items 1–5.

Dependencies

• Client-side companion (now a compatibility shim, not a bug): ogc-client-CSAPI_2#168. When this server issue ships and a new Go release is cut, the shim there can be deprecated and eventually removed.
• Related server strictness patterns: #5, #7.

Operational Constraints

⚠️ MANDATORY: Before starting work on this issue, review docs/governance/AI_OPERATIONAL_CONSTRAINTS.md if available.

• Precedence: OGC specifications → AI Collaboration Agreement → This issue description → Existing code → Conversational context.
• No scope expansion; minimal diffs; ask when unclear.
• This code is upstream — coordinate with the maintainer if contributing back.

References

#	Reference	Role
1	OGC 23-002r0 §13.3.2, /req/advanced-filtering/obs-by-resulttime (A–D)	Normative requirement being violated
2	OGC 23-002r0 §13.3.1, /req/advanced-filtering/obs-by-phenomenontime	Parallel requirement for phenomenonTime
3	OGC 23-001r0 §8.7, /req/api-common/datetime	datetime query parameter (systems/deployments/samplingFeatures)
4	OGC 23-002r0 Annex A.6 — /conf/advanced-filtering/obs-by-resulttime	Abstract test that currently fails
5	internal/model/query_params/query_params.go	Root cause — temporal parser no-op
6	CSAPI Go Integration Report §12–§13	Full investigation context and empirical test log
7	ogc-client-CSAPI_2#168	Downstream client-side compatibility shim (now scoped as such)

---

Original filing (superseded — kept verbatim for historical transparency)

Finding (original)

resultTime=latest temporal query parameter is not implemented — the server either rejects or ignores the latest keyword, forcing clients to implement a multi-step fallback pattern at every call site.

Review Source: ISS map investigation during live integration testing against the Go CSAPI server (documented in CSAPI Go Server Integration Report §12).
Severity: P3-Minor
Category: API Design
Ownership: Upstream (SomethingCreativeStudios/connected-systems-go)

Problem Statement (original)

The OGC Connected Systems API specification defines resultTime=latest as a temporal filter shorthand to retrieve the most recent observation(s) from a datastream. The Go server does not implement this keyword — requests with resultTime=latest return empty results or an error instead of the latest observation.

Affected code — temporal parameter handling in internal/model/query_params/:

The BuildFromRequest() method parses resultTime as a time range but does not recognize the latest keyword as a special case. When latest is passed, it likely fails to parse as an ISO 8601 timestamp and is silently discarded, resulting in no temporal filter being applied or an empty result set.

Scenario:

# Datastream has 500+ observations spanning several days
GET /datastreams/{id}/observations?resultTime=latest

# Expected: 1 observation — the most recent by resultTime
# Actual: empty result set or parse error

# Workaround — client must use limit+sort:
GET /datastreams/{id}/observations?limit=1
# Returns the most recent observation (assuming default sort is newest-first)

Impact: Every client that uses resultTime=latest to fetch the current/most-recent observation must implement a fallback pattern. In the CSAPI Explorer (MapViewPage.vue), this required a retry block at 7 separate call sites:

// Fallback pattern repeated 7 times in MapViewPage.vue
let obs = await fetchObservations(dsId, { resultTime: 'latest', limit: 1 });
if (!obs || obs.length === 0) {
  obs = await fetchObservations(dsId, { limit: 1 });
}

SensorHub supports resultTime=latest natively, so this is a Go-server-specific gap that causes divergent client behavior when targeting different CSAPI backends.

Ownership Verification (original)

This is a missing feature in the upstream SomethingCreativeStudios/connected-systems-go repository. The OS4CSAPI fork is currently synced with upstream (main branch is up to date).

Conclusion: This is upstream — the temporal query parameter parsing has never included latest keyword support.

Files to Modify (original)

File	Change	Est. lines	Notes
internal/model/query_params/query_params.go (or temporal parameter handler)	Modify	~15	Add latest keyword recognition in temporal parameter parsing
internal/repository/observation_repository.go	Modify	~10	Translate latest into ORDER BY result_time DESC LIMIT 1 query
e2e/	Modify	~20	Add E2E test for resultTime=latest

Proposed Solutions (original)

Option A: Translate latest to ORDER BY ... DESC LIMIT 1 (Recommended)

When the temporal parameter parser encounters latest as the value, instead of trying to parse it as an ISO 8601 timestamp, set a flag or special value that the repository layer translates into ORDER BY result_time DESC LIMIT 1.

Pros: Minimal change; matches SensorHub behavior; spec-aligned; no client workaround needed.
Cons: Requires touching both the query param parser and the repository layer.
Effort: Small. Risk: Low.

Option B: Rewrite latest to time range in middleware

Intercept resultTime=latest at the handler level and rewrite it to resultTime=<now-1s>/<now> (or a very recent time window), letting the existing temporal range logic handle it.

Pros: No repository changes needed.
Cons: Fragile — defining "latest" as a fixed time window is semantically wrong; may miss the actual latest observation if there's a gap.
Effort: Small. Risk: Medium.

Scope — What NOT to Touch (original)

• ❌ Do NOT modify files outside the "Files to Modify" table above.
• ❌ Do NOT refactor adjacent code that isn't part of this finding.
• ❌ Do NOT change how other temporal parameters (phenomenonTime, validTime) are parsed unless they share the same parser path.
• ❌ Do NOT implement latest for non-observation resource types (it only applies to temporal result sets).

Acceptance Criteria (original)

• GET /datastreams/{id}/observations?resultTime=latest returns the single most recent observation by resultTime.
• GET /datastreams/{id}/observations?resultTime=2024-01-01/2024-12-31 still works unchanged (explicit time ranges unaffected).
• Existing tests still pass (make test).
• E2E test added verifying resultTime=latest returns the most recent observation.

Dependencies (original)

Blocked by: Nothing. Blocks: Nothing.
Related: ogc-client-CSAPI_2#168 — Client library resultTime=latest fallback (client-side companion); #5 — Strict schema validation (related pattern of server strictness).

References (original)

#	Reference	Role
1	internal/model/query_params/query_params.go — temporal parsing	Root cause — latest keyword not recognized
2	OGC 23-001 §9.4 — Temporal filtering	Spec defines resultTime parameter including keyword values
3	CSAPI Explorer MapViewPage.vue — 7 fallback sites	Real-world workaround demonstrating impact
4	ogc-client-CSAPI_2#168	Client-side companion issue
5	Integration Report §12	Investigation that discovered this gap

Why this framing was superseded

Empirical re-test showed the server does not reject or return empty for resultTime=latest; it silently returns its default unfiltered page, and does the same for every value of resultTime, phenomenonTime, and datetime. The defect is broader than the latest keyword. The spec reference was also sharpened from OGC 23-001 §9.4 (which covers systems/deployments temporal filtering) to OGC 23-002r0 §13.3.2 (which is the observations-specific requirement including the latest keyword mandate at statement D). Both corrections are reflected in the rewritten body above.

[Sam-Bolling]

Update (2026-04-18) — Diagnosis Corrected After Empirical Re-Test

A follow-up investigation was triggered by a related finding (deployment-hierarchy gap, see CSAPI Go Server Integration Report §13). In the course of that work I re-ran the resultTime=latest scenarios directly against the live Go server and discovered that the original problem statement on this issue is wrong in a specific and important way. This comment documents (1) how the original diagnosis was reached, (2) what the server actually does, and (3) what the real underlying defect is, so that the evolution of this finding is preserved rather than rewritten.

1. How we got the original diagnosis

The original report (Integration Report §12.3) noted that resultTime=latest handling was "inconsistent — sometimes returning empty result sets, sometimes succeeding." The Explorer's buildSystemLocationCache() was intermittently not locating the ISS position, and applying a resultTime=latest → limit=1 fallback at 7 call sites in MapViewPage.vue visibly fixed the symptom. That correlation was interpreted as evidence that the latest keyword wasn't being parsed, leading to this issue's framing: "returns empty results or an error."

There was already a caveat in §3.4 of the report ("Subsequent curl testing confirmed that resultTime=latest + limit=1 combined does return valid data"), but this issue was filed before that caveat was reconciled with the original framing.

2. What the Go server actually does (empirical test 2026-04-18)

Tested against the live ISS Position datastream (db6756eb-e4ed-47e9-94c2-02eff5edf8d4) on https://129-80-248-53.sslip.io/csapi-go:

Request	HTTP	Items	Newest	Oldest
?limit=1	200	1	21:18:18	21:18:18
?resultTime=latest	200	10 (default page)	21:18:18	21:13:48
?resultTime=latest&limit=1	200	1	21:18:18	21:18:18
?resultTime=latest&limit=50	200	50	21:18:18	20:53:48
no params	200	10	21:18:18	21:13:48
?resultTime=2099-01-01/2099-12-31 (future)	200	1000 (today's data)	21:18:48	12:59:18
?resultTime=1999-01-01/1999-12-31 (past)	200	1000 (today's data)	21:18:48	12:59:18
?resultTime=frobnicate (gibberish)	200	1000 (today's data)	21:18:48	12:59:18

The server:

• Never returns an empty set
• Never returns an error
• Never applies any temporal filtering
• Silently discards every value of resultTime — including latest, far-future ranges, far-past ranges, and literal gibberish

3. The real defect

This is not a missing-latest-keyword bug. It is a broader bug: the temporal parameter parser in internal/model/query_params/ accepts any string value for resultTime (and, per §13.3 of the integration report, for phenomenonTime and datetime as well) and applies no filter. The full unfiltered result set is returned, subject only to limit.

resultTime=latest + limit=1 appears to work only by accident: the server's default descending sort + limit=1 incidentally returns the most-recent observation regardless of whether the latest keyword is honored.

4. What this means for the 7-site Explorer fallback

The if (empty) retry with limit=1 branch added to MapViewPage.vue is never triggered against the Go server — the first call always returns data. The fallback is effectively dead code on Go and has always been unnecessary on OSH (which honors the keyword natively). The visible "fix" during the original investigation was almost certainly caused by one of the other confounders active at the time:

• Cloudflare Pages serving a stale bundle missing the @link.href fix (documented in §13.4)
• The descending-order dedup bug in loadObservationLayers() producing empty polylines (§13.1)
• ISS systems rendering off-screen at their real-time orbital position (§12.4)

None of those were caused by resultTime=latest parsing.

5. Corrected problem statement

Aspect	Original (this issue as filed)	Corrected
Symptom	"Returns empty results or an error"	Returns unfiltered result set (param silently ignored)
Scope	latest keyword only	All values of resultTime/phenomenonTime/datetime
Client impact	"Forces multi-step fallback at every call site"	No fallback actually needed; limit=N alone returns N most-recent
Root location	latest keyword case in temporal parser	Whole temporal-filter code path is effectively a no-op
Severity	P3-Minor	P3-Minor still, but the broader P3 is the silent-ignore-everything behavior

6. Recommended disposition

• Keep this issue open but re-scope the title/body to "Temporal filters (resultTime, phenomenonTime, datetime) silently ignored on observations — unfiltered result set returned regardless of value", with latest as one specific instance.
• Option A from the original proposal (translate latest → ORDER BY result_time DESC LIMIT 1) is still the right fix for the keyword case, but should be paired with proper rejection/validation of unparseable values (HTTP 400 with a clear message) so clients can detect malformed temporal parameters rather than silently getting every observation in the database.
• Acceptance criteria should be extended to cover:
  • Rejecting unparseable temporal values with HTTP 400
  • Applying time-range filters correctly when valid ranges are supplied
  • Honoring latest per OGC 23-001 §9.4
• Related: ogc-client-CSAPI_2#168 — the client-side companion issue should also be revisited in light of these findings. I'm leaving that one untouched for now so it can be reviewed separately.

7. Provenance

• Original symptom observed: 2026-04-17 during ISS map investigation (§12.3 of the Integration Report)
• Explorer 7-site fallback applied: 2026-04-17 (commit 2f0869a lineage)
• Issue Temporal query parameters (resultTime, phenomenonTime, datetime) silently ignored — all values discarded, including latest #11 filed: 2026-04-17 based on symptom-level diagnosis
• Empirical re-test and correction: 2026-04-18 (this comment), triggered by §13 follow-up investigation
• No code changes are proposed in this update — only a corrected problem statement. The original description above remains as the starting point of the diagnostic trail.

[Sam-Bolling]

Spec citation — normative requirement Go is violating

Adding the normative reference for completeness. The behavior documented in the previous comment (silent no-op on resultTime=latest, and in fact on all resultTime / phenomenonTime / datetime values) is not just a "missing convenience feature" — it is a conformance failure against the published draft standard.

Source: OGC API — Connected Systems — Part 2: Dynamic Data (OGC 23-002r0), Clause 13.3.2 — "Result Time Filter."

Requirement /req/advanced-filtering/obs-by-resulttime:

A	The HTTP GET operation at an Observation resources endpoint SHALL support a parameter resultTime.
B	The parameter SHALL fulfill the same requirements as the parameter datetime defined in Clause 7.15.4 of OGC API — Features — Part 1: Core.
C	Only the resultTime property of Observation resources SHALL be used to determine the temporal extent evaluated against the parameter.
D	In addition to the possible parameter values defined in OGC API — Features — Part 1: Core, the parameter SHALL also support the special value latest. When this special value is used, only observations with the latest result time SHALL be included in the result set.

Spec example (verbatim):

{api_root}/datastreams/123/observations?resultTime=latest

Parallel requirement for phenomenonTime lives at Clause 13.3.1 (/req/advanced-filtering/obs-by-phenomenontime) with the same A/B/C structure.

What this means concretely

• Statements A–C are violated because Go accepts the parameter name but does not use it to filter. Any resultTime=<interval> request returns the same unfiltered page as if the parameter were absent.
• Statement D is violated because the keyword latest is neither honored nor rejected — it is silently discarded along with every other value.
• The abstract test suite for this requirement (Annex A.6, /conf/advanced-filtering/obs-by-resulttime) would fail on the current implementation: the test issues a bounded resultTime query and verifies every returned observation's resultTime intersects the requested window. Go's response does not satisfy that post-condition.

No change to the diagnosis or recommendation in the previous comment — this is just the normative hook so whoever picks up the fix has the exact requirement URI and abstract-test identifier to target:

• Requirement URI: /req/advanced-filtering/obs-by-resulttime
• Conformance test URI: /conf/advanced-filtering/obs-by-resulttime
• Document: https://docs.ogc.org/DRAFTS/23-002r0.html#_f37a5074-0000-0000-0000-13-3-2 (Clause 13.3.2)

This reinforces the conclusion from the updated issue body: the fix belongs on the server side. The client-side &limit=1 workaround used by ogc-csapi-explorer is compensation for a non-conformant server, not a missing library feature.

[Sam-Bolling]

Cross-project update — additional findings from ogc-client-CSAPI_2 Phase 8 triage (2026-04-29)

While triaging OS4CSAPI/ogc-client-CSAPI_2#168 (originally a proposed client-side compatibility shim for this issue, now closed wontfix because the client is spec-correct), some additional empirical findings surfaced that may be useful here. Sharing in case they help characterize the root cause or scope the fix.

The gap appears broader than resultTime=latest

Probes against https://129-80-248-53.sslip.io/csapi-go (recorded in ogc-client-CSAPI_2#168 and now in our repo's references.md "Known Server Conformance Gaps"):

Request	Observed
?resultTime=latest	200 OK, default page (10 items, unfiltered)
?resultTime=latest&limit=1	200 OK, 1 item — newest by descending-default-sort accident
?resultTime=frobnicate	200 OK, default page (no validation, value silently discarded)
?resultTime= (empty)	200 OK, default page from today

The pattern — silent acceptance of every value, including invalid ones, with no temporal filtering applied — strongly suggests the parser path is a no-op rather than a latest-keyword-specific gap. By extension, since the OGC 23-002 temporal family on observation endpoints is {datetime, phenomenonTime, resultTime, issueTime, executionTime}, the same probe pattern would likely show all five as non-functional. Not all five have been individually probed against this build; the assumption that the gap covers the family is informed by the uniform behavior across the values that have been probed. Worth a single ?phenomenonTime=2026-01-01T00:00:00Z/2026-01-02T00:00:00Z probe to confirm.

Spec citation

OGC 23-002r0 §13.3.2 /req/advanced-filtering/obs-by-resulttime statement D is unambiguous on the latest keyword:

"the parameter SHALL also support the special value latest. When this special value is used, only observations with the latest result time SHALL be included in the result set."

The broader temporal parameters are mandated by §13.3.x and the Common-Query parameter family.

Server-validation observation that may help scope a fix

Since ?resultTime=frobnicate returns 200, parameter validation is silently bypassing the temporal parser entirely. Whatever fix lands for latest should probably also reject syntactically invalid temporal values with a 400, and/or log the rejection — otherwise consumers (us included) have no signal that a temporal filter was supplied but ignored. The current "200 OK with unfiltered page" behavior is the worst possible failure mode: it masquerades as success.

Why we closed our #168 rather than ship a client-side shim

In case it's useful context for prioritizing this:

1. Our library serializes every temporal parameter and the latest keyword correctly per OGC 23-002 (verified — no client-side bug exists).
2. A shim targeting resultTime=latest would address one keyword of one parameter of five; the gap on the server side appears to cover the whole temporal family, so a per-keyword shim would be selective and unprincipled.
3. The fallback URL pattern (plain ?limit=1) only "works" against servers whose default sort is descending — true for Go, not true for SensorHub (ascending). A client-side shim that hides this detail would silently mis-rank against SensorHub.
4. We didn't want to ship a method whose deprecation is already scheduled for the moment this issue ships.

So: this server fix is on the critical path for our consumers in a way that a workaround in our library wouldn't be. The cleaner the fix here, the less consumer-side scar tissue downstream.

Cross-references

• OS4CSAPI/ogc-client-CSAPI_2#168 — closed wontfix; full Phase 8 reasoning in the status banner. Probe table preserved there and in references.md.
• OS4CSAPI/connected-systems-go#5 — companion server gap (?uid= filter silently ignored). Same shape of bug (silent acceptance, no validation, ineffective filter); likely related at the request-handling layer.
• Our references.md "Known Server Conformance Gaps" — Gaps 1 and 2 record both this issue and #5 with empirical detail and our client-side disposition for each.
• A consumer-side ergonomic fix for the MapViewPage.vue workaround sites is being filed in the ogc-csapi-explorer repo today (operation 2 of the same Phase 8 triage that closed #168).

Happy to provide more probe data or test against a fix branch if useful.

[Sam-Bolling]

Empirically validated. Real defect, P2-Important firm; defensible P1 case (silent HTTP 200 with stale full page).

Verdict: VALIDATED with refined framing

Tested against https://129-80-248-53.sslip.io/csapi-go-head at repo 175f263. Seeded three observations on a single datastream with resultTime of 2024-01-15, 2025-06-15, 2026-04-29, then ran nine probes against GET /datastreams/{id}/observations:

#	query	expected	observed
1	resultTime=latest	1 obs (most recent)	200 / 3 obs
2	resultTime=latest&limit=1	1 obs	200 / 1 obs (by accident — LIMIT 1 on unfiltered ORDER BY result_time DESC)
3	resultTime=2099-01-01T00:00:00Z/2099-12-31T23:59:59Z	0 obs	200 / 3 obs
4	resultTime=frobnicate	HTTP 400	200 / 3 obs
5	resultTime=2024-01-01T00:00:00Z/2024-01-31T23:59:59Z	1 obs	200 / 3 obs
6	phenomenonTime=now	filtered or 0	200 / 3 obs
7	phenomenonTime=2025-01-01T00:00:00Z/2025-12-31T23:59:59Z	1 obs	200 / 3 obs
8	resultTime=../2024-12-31T23:59:59Z (open-start)	1 obs	200 / 3 obs
9	resultTime=2025-01-01T00:00:00Z/.. (open-end)	2 obs	200 / 3 obs

Every value of resultTime / phenomenonTime produces the unfiltered default page. The reporter's empirical claims reproduce exactly.

Refinement to mechanistic framing

The "entire parser is a no-op" framing is slightly too strong. The handler / repository / SQL WHERE-builder are correctly wired:

• internal/api/observation_handler.go calls ObservationsQueryParams{}.BuildFromRequest(r) for both ListObservations and ListDatastreamObservations.
• internal/repository/observation_repository.go::applyFilters lines 109–127 add WHERE phenomenon_time … and WHERE result_time … whenever the parsed TimeRange has at least one non-nil bound.

The defect is isolated to one dispatch path in internal/model/common_shared/time_range.go:

// observation_query_params.go::BuildFromRequest
if vals := r.URL.Query()["resultTime"]; len(vals) > 0 {
    tr := common_shared.ParseTimeRange(vals)   // vals is []string
    params.ResultTime = &tr
}

// time_range.go::ParseTimeRange
switch v := value.(type) {
case []string:
    return ToTimeRangeFromSlice(v)   // <-- this branch is taken
case string:
    return ToTimeRange(v)            // <-- never reached from HTTP handlers
}

ToTimeRangeFromSlice does none of the spec-required parsing:

• It feeds each element into time.Parse(time.RFC3339, parts[0]) directly. The OGC interval form 2024-01-01T00:00:00Z/2024-01-31T23:59:59Z arrives as vals = []string{"2024-01-01T00:00:00Z/2024-01-31T23:59:59Z"} (one element with a / inside), time.Parse fails on the slash, startTime stays nil.
• It does not recognise the keywords latest, now, .., ../... Those only exist in ToTimeRange(string), which is never reached for HTTP query parameters.
• time.Parse errors are silently dropped (if err == nil { startTime = &t }). Nothing propagates to the handler, so garbage like ?resultTime=frobnicate cannot be detected — the handler returns HTTP 200 with the unfiltered page rather than the HTTP 400 that OGC API – Features Part 1 §7.15.4 requires.

When Start == nil && End == nil, applyFilters enters the outer if params.ResultTime != nil { ... } but none of the three inner branches match, so no WHERE clause is added.

Spec authority

• CSAPI Part 2 §13.3 defines resultTime and phenomenonTime and inherits the interval grammar from OGC API – Features Part 1 §7.15.4.
• OGC API – Features Part 1 §7.15.4 requires HTTP 400 for invalid temporal values.
• CSAPI Part 2 §13.3.2 statement D normatively defines the latest keyword for resultTime on observation collections.

The richer ToTimeRange(string) already in the codebase explicitly recognises latest, now, .., ../.. and the start/end split — so spec awareness is present in the file. The bug is just that the handler-side dispatch lands on the wrong helper.

Severity

P2-Important is firm. P1 is defensible because the failure is silent and at HTTP 200 — downstream agents polling ?resultTime=latest every interval receive limit-default rows of stale data with no signal that the filter never executed. This is qualitatively the same shape as a missing WHERE clause in a database query: the response is well-formed but unrepresentative of the filter the client requested.

Suggested fix sketch (small, localised)

In each *_query_params.go::BuildFromRequest, replace ParseTimeRange(vals) with the string-aware path:

tr := common_shared.ToTimeRange(strings.Join(vals, "/"))

Or extend ToTimeRangeFromSlice to detect a single element containing / or matching a keyword and delegate to ToTimeRange(string). Either way: surface time.Parse errors so the handler can return HTTP 400 on unparseable input, instead of silently degrading to "no filter".

A complete fix should also extend coverage to datetime on systems / deployments / sampling-features collections per OGC 23-001r0 §8.7. That scope is mentioned in the issue but was not empirically probed in this evaluation.

Not filing follow-ups

The "missing filter" defect and the "no HTTP 400 on garbage" defect collapse into the same parse-path fix. No separate follow-up issues filed.

---

This is a research-only evaluation; no source files in this repo were modified. Static analysis, live verification, and spec authority notes are in docs/research/evidence/issue-011/ and docs/research/issue-evaluations/issue-011.md. The three test observations seeded on datastream cf4cd80c-ddc1-4470-815c-292a68463f3e were deleted (HTTP 204 each) after testing.

[Sam-Bolling]

Closing as completed. Verified end-to-end on upstream/main post-merge 22e8bcd.

Resolution

@SomethingCreativeStudios on the upstream triage pass:

"mostly just a dip from time range related bug"

i.e. #11 collapses into the time range / better-400 fix track that landed across 1b2b614 (Adding support for "latest" for TimeRange) and c2ab201 (time range and better 400 (now includes more info and field info)). The headline defect from this issue — every value of resultTime / phenomenonTime silently discarded, including latest — is repaired.

The maintainer's read tracks the evaluation refinement that the defect was isolated to one parse-side dispatch path, not "the entire parser." That dispatch path was rebuilt.

What the fix actually delivers

1. New strict parser with proper interval / keyword grammar

Two new symbols in internal/model/common_shared/time_range.go:

// Latest signals "most recent record only" semantics (the ?resultTime=latest
// query keyword). When true, Start/End are ignored by the repository and the
// query uses ORDER BY <time_col> DESC LIMIT 1 instead of a WHERE filter.
type TimeRange struct {
    Start  *time.Time `json:"start,omitempty"`
    End    *time.Time `json:"end,omitempty"`
    Latest bool       `json:"-"`
}

// ParseTimeRangeStrict parses a query parameter value into a TimeRange,
// returning an error when a non-special value cannot be parsed as RFC3339.
// Use this for request query parameter validation where garbage input
// should produce HTTP 400. Accepts string or []string. Special values
// ("latest", "now", "..", "../..") are accepted. ".." is allowed in range
// parts to mean unbounded.
func ParseTimeRangeStrict(value interface{}) (TimeRange, error) { ... }

ToTimeRange(string) was also expanded to recognise the latest and now keywords and ../.. open-bound forms, replacing the silent-failure time.Parse calls.

2. Strict path wired into observation handler

internal/model/query_params/observation_query_params.go now dispatches both spec parameters through the strict path, with errors bubbled to the handler so HTTP 400 is returned on garbage:

if vals := r.URL.Query()["phenomenonTime"]; len(vals) > 0 {
    tr, err := common_shared.ParseTimeRangeStrict(vals)
    if err != nil {
        return nil, fmt.Errorf("invalid phenomenonTime: %w", err)
    }
    params.PhenomenonTime = &tr
}

if vals := r.URL.Query()["resultTime"]; len(vals) > 0 {
    tr, err := common_shared.ParseTimeRangeStrict(vals)
    if err != nil {
        return nil, fmt.Errorf("invalid resultTime: %w", err)
    }
    params.ResultTime = &tr
}

3. latest semantics correctly honoured at the repository

internal/repository/observation_repository.go applyFilters now branches on Latest, executing ORDER BY … DESC LIMIT 1 instead of a WHERE clause — matching CSAPI Part 2 §13.3.2 statement D:

// "latest" mode: return the single most-recent observation ordered by the
// requested time column, bypassing normal pagination.
latestResultTime := params.ResultTime != nil && params.ResultTime.Latest
latestPhenomenonTime := params.PhenomenonTime != nil && params.PhenomenonTime.Latest
if latestResultTime || latestPhenomenonTime {
    orderCol := "result_time"
    if latestPhenomenonTime {
        orderCol = "phenomenon_time"
    }
    err := query.Order(orderCol + " desc").Limit(1).Find(&observations).Error
    return observations, int64(len(observations)), err
}

And the regular WHERE branches now correctly skip themselves when Latest=true (!params.PhenomenonTime.Latest / !params.ResultTime.Latest), so the ORDER BY … LIMIT 1 mode isn't accidentally double-filtered.

4. Strict-path coverage extended beyond observations

ParseTimeRangeStrict is also wired into the query-param builders for command, control_stream, datastream, deployment, and system_event — so the same latest / .. / RFC3339-or-400 contract applies to every list endpoint that has a temporal filter. feature_query_params.go retains its own parseDateTime helper for the OGC datetime parameter shape on sampling features.

5. Regression coverage

internal/model/common_shared/time_range_test.go adds eight test cases that pin the new contract:

Test	Asserts
TestParseTimeRangeStrict_ValidRange_OK	2026-01-01T00:00:00Z/2026-12-31T23:59:59Z parses cleanly
TestParseTimeRangeStrict_TwoElementSlice_OK	repeated query-param style [start, end] slice form parses cleanly
TestParseTimeRangeStrict_Garbage_ReturnsError	frobnicate produces an error (→ HTTP 400, not silent 200)
TestParseTimeRangeStrict_GarbageInRange_ReturnsError	partial garbage frobnicate/2026-12-31T23:59:59Z produces an error
TestParseTimeRangeStrict_LatestKeyword_SetsLatestFlag	latest flips Latest=true
TestToTimeRange_LatestKeyword_SetsLatestFlag	string-form latest also flips the flag
TestParseTimeRangeStrict_DotDot_OK	bare .. accepted as unbounded
TestParseTimeRangeStrict_OpenEndedRange_OK	2026-01-01T00:00:00Z/.. accepted as open-end interval

Each one targets a specific pre-fix failure mode from the issue's nine-probe live test.

Mapping fix → original claims

Live probe in issue body	Pre-fix behaviour	Post-fix behaviour
?resultTime=latest	200 + full unfiltered page	200 + single most-recent observation (DESC LIMIT 1)
?resultTime=latest&limit=1	accidentally returned 1 (LIMIT-of-unfiltered)	200 + single most-recent observation, by spec
?resultTime=2099-01-01T00:00:00Z/2099-12-31T23:59:59Z	200 + full page	200 + 0 observations (proper WHERE clause)
?resultTime=frobnicate	200 + full page (silent)	400 with field-info error body
?resultTime=<narrow valid window>	200 + full page	200 + filtered to window
?phenomenonTime=now	200 + full page	200 + observations with phenomenon_time >= now (start-only bound)
?phenomenonTime=<narrow valid>	200 + full page	200 + filtered to window
?resultTime=../2026-… (open-start)	200 + full page	200 + phenomenon_time <= end-bound
?resultTime=2026-…/.. (open-end)	200 + full page	200 + phenomenon_time >= start-bound

All nine pre-fix failure modes are repaired. The HTTP 400-on-garbage behaviour additionally closes the silent-failure spec gap noted in the evaluation §6 (Features Part 1 §7.15.4 requires 400 on invalid values).

Out-of-scope follow-up (noted, not blocking)

The evaluation's §6 secondary-scope mention — extending the datetime parameter to /systems — was not addressed in this fix track. git grep on upstream/main confirms DateTime is wired on deployment_query_params.go and feature_query_params.go (sampling features) and system_event_query_params.go, but system_query_params.go does not parse datetime and system_repository.go does not filter on it. CSAPI Part 1 §7.4.4 specifies validTime-based filtering on systems, so this is a real but separate gap. Not in scope for #11 as triaged ("mostly just a dip from time range related bug" is fairly specifically about the parse-side dispatch on observations). If needed, a follow-up issue against SomethingCreativeStudios/connected-systems-go would be the right venue.

Cross-references

• Original evaluation: docs/research/issue-evaluations/issue-011.md (T1–T9 live transcripts, static dispatch trace through ParseTimeRange → ToTimeRangeFromSlice showing the silent-failure mode).
• Fix-side commits: 1b2b614 (Adding support for "latest" for TimeRange) + c2ab201 (time range and better 400 (now includes more info and field info)).
• Companion issues collapsed onto same fix per maintainer's triage: TimeRange.UnmarshalJSON silently swallows non-string and parse-failed times — Datastream POST stores empty TimeRange without error #18 (datetime range → 400 on bad data), decodeObservationPayload silently drops numeric phenomenonTime; should reject symmetrically with resultTime #19 (PhenomenonTime guard), Misleading error 'resultTime is required' when field is present but wrong type #20 (overhauled error handling — surfaces the validation error to the client).

Closing as completed.