get_default_trace_events filters in UTC but returns event_time in server-local time, unmarked

[erikdarlingdata]

get_default_trace_events filters in UTC and returns event_time in the monitored server's LOCAL time, with nothing on the response saying so. Every correlation against another surface is silently off by the server's UTC offset.

Measured

Server kappa (kappa-01, US Eastern, UTC-4).

Call A — as_of=2026-09-09T05:30:00Z, hours_back=3 (UTC window 02:30–05:30). Returned 22 events, timestamped 00:28:02 through 01:22:01. None of those labels is inside the window requested.

Call B — as_of=2026-09-09T04:35:00Z, hours_back=1 (UTC window 03:35–04:35). Returned exactly the 6 events labelled 00:28:02–00:28:21, and correctly dropped the 00:44 and 01:22 ones.

That is the discriminating result. The narrower UTC window kept precisely the events whose labels plus four hours (04:28) fall inside it, and excluded the ones whose labels plus four hours (04:44, 05:22) fall outside. The filter is correct and operating in UTC; the rendered event_time is local.

Why it matters beyond cosmetics

collection_log / get_collection_log collection_time, list_servers last_collection, and this tool's own as_of parameter are all UTC. event_time is not, and no field, note or suffix marks it.

So the natural operation — line trace events up against a collector error or an incident window — is wrong by the offset, and wrong in the direction that inverts causality: an event that really happened at 04:28 UTC reads as 00:28, appearing to precede a 04:28 collector error by four hours rather than coinciding with it.

Found while correlating a real incident. kappa logged "Database 'kappa' cannot be opened. It is in the middle of a restore" at 04:28:06 UTC; this tool reports the matching SQLServerHostManager object alters at "00:28:04" and "00:28:21". They are the same twenty seconds. Read as printed, they are four hours apart and unrelated.

I only noticed because the returned times fell outside the window I had asked for. A caller who asked for a wide window would get plausible-looking timestamps and no signal at all that they were in a different frame.

Fix options, in preference order

1. Return UTC, matching every neighbouring surface and the tool's own as_of. Cleanest, and a behaviour change callers may be compensating for.
2. Keep local but say so unambiguously — rename to event_time_local, add the offset as its own field, and state it in the tool description. Weaker: it leaves two frames on one response.

Whichever way, the tool description should state the frame explicitly. It currently documents as_of as UTC and says nothing about the returned column, which is what makes the mismatch invisible.

Check the siblings before closing

get_default_trace_events is unlikely to be the only reader of a trace/XEvent-sourced timestamp. Worth a sweep of the other event-shaped surfaces (get_health_parser_*, get_deadlocks, get_blocked_process_*, get_system_health_events) for the same pattern rather than fixing this one in isolation — a mixed-frame response set is worse than a consistently wrong one, because it defeats the workaround.

[erikdarlingdata]

Claude posting for Erik Darling

Two additions: an independent reproduction, and prior art that makes this the second instance of one class rather than a one-off.

Reproduced independently. A second reader ran as_of=2026-09-09T04:35:00Z, hours_back=1 against the same server and got an event labelled 00:34:06 — a different event from the six in the report above, same four-hour offset, same UTC-4. Two readers, two different events, one offset.

This class has been fixed here before. #2991 — "query_stats.creation_time is compared against a naive-UTC bound, so PARAMETER_SENSITIVITY is scored against the wrong plan population" — is the same defect on a different column, and #2992 shipped the de-skew for it. So the codebase already carries a worked solution to "a SQL Server timestamp is in server-local time and something downstream assumes UTC," and whoever takes this should read #2992 before writing anything new; there may be a helper to reuse rather than a fix to invent.

It also sharpens the sibling sweep this issue asks for. The recurrence is the argument: two independent surfaces have now shipped the same skew, which makes it a property of how SQL Server timestamps enter this system rather than a mistake someone made twice. A guard that asserts the frame at the boundary would be worth more than a third point fix — and #2992's fix is the natural place to look for where that boundary already is.

One note on severity, unchanged from the report: the failure is silent and directionally misleading rather than merely wrong. An event at 04:28 UTC renders as 00:28 and reads as having preceded a 04:28 error by four hours instead of coinciding with it. Nothing on the response contradicts that reading.

[erikdarlingdata]

Claude posting for Erik Darling

Fixed by #3202, merged to dev as 9cd4ca29dc05. Closing by hand — closing keywords resolve against main and this landed on dev.

event_time is now de-skewed to UTC at every Darling read boundary. Converting rather than marking was not a judgement call: the repo had already answered it on this same column twice — the viewer's own SQL projects dte.event_time - make_interval(mins => svr.offset_minutes), and Lite's identically-named get_default_trace_events already returned a de-skewed EventTimeUtc. Marking would have made the Darling MCP the only local-frame timestamp in the tree while contradicting the same-named tool in the other SKU. CpuUtilizationSql does the same for sample_time under #2992.

sample_time is not a contrary convention, which was the thing most likely to be read as one: ServerSummaryCpuSql and FleetCpuSql carry no time predicate on it, because bounding a server-local column against store time returns zero rows. That is about filtering a column whose value is never returned. Where such a column is returned, it is de-skewed. One rule — store raw local, convert at the read boundary.

Three things worth keeping.

Two existing pins asserted the defect. EventsByWindowSql_ReadsBaseTables_WindowsOnServerLocalEventTime required event_time >= $2 and deliberately did not assert a projected event_time_utc — holding the half-fix in place, in the same test project as the viewer's pin asserting the de-skew on the same column. DarlingComposeTests pinned f.event_time AS ts.

A second surface had the same defect, found by sweeping rather than by reading the report: the compose annotation overlay bounded a naive-UTC window against the local column and plotted it on a UTC axis beside four annotation sources that are UTC. Two frames in one chart, which is the case this issue names as worse than a uniform error.

One correction to this issue. It says the filter "is correct and operating in UTC". The filter was correct but operating in local — it converted the bounds into local. Indistinguishable from outside, since row selection is identical, but it is why the projection was the only thing left wrong and why a row-count test would have passed.

Two findings about the instruments, both of which cost more than the defect did:

A false universal was written four times, after the sweep that disproved it. The change initially claimed event_time was UTC "like every timestamp on every read here", and repeated the claim in the tool Description (which ships in the MCP schema every client reads, so it reaches an agent even when the instruction text does not) and twice more in a reader doc comment. The sibling sweep in this same work had already found six other tools returning server-local timestamps, two of them mixing frames inside one payload. Three independent bot reviews read that diff and none of the four registered — a claim that flatters the change it documents gets audited least. All four are now scoped to this tool and name the specific surfaces they correlate against.

A duplicate parameter bind is caught by nothing. Scoping the offset join could have been done with a second AddTextArray of the same value: it compiles, reads correctly, and silently shifts every downstream ordinal. With the new pin's ordinal substring and its parameter-count assert both removed, that mutation passes all 273 tests — DarlingComposeTests' own ordinal assertions included, because the annotation sources they check never take this join. The compose compiler has no general duplicate-bind guard; filed separately.

Verified against real PostgreSQL 17: 273 tests, Failed: 0, Skipped: 0, Not Run: 0, 17 mutations all red — five of them on the instruments rather than the subject.