No guard scans a payload or render projection for a server-local column handed to a UTC-assuming consumer

[erikdarlingdata]

Three clock-frame defects of one shape have now been found by hand — #2991 (query_stats.creation_time in analysis SQL), #3198 (default_trace_events.event_time in an MCP payload), and the sibling sweep for #3202 that found 16 more MCP fields plus 8 desktop render sites. Nothing in either test suite scans a payload or render projection for a server-local column being handed to a consumer that assumes UTC. A guard over that boundary would have caught all three at once, and it is the more valuable half of the work.

What the three existing guards do and do not reach

Guard	Roots	Hunts	Why it cannot see this
CreationTimeClockFrameDisciplineTests	Darling/PerformanceMonitor.Darling.Analysis, Lite/Analysis	bare creation_time compared against a $n window bound	right discriminator shape, wrong roots — neither Service/Mcp/ nor either viewer is in its globs
StoreSqlClockDisciplineTests	store source incl. Service/Mcp/	naive timestamp column compared against a bare clock function	right roots, wrong hazard, and it explicitly disclaims projections at :43-47: "a bare clock in a SET, a VALUES row or a projection is a different defect shape … deliberately out of scope"
CollectorTimestampFrameTests	PerformanceMonitor.Collectors	the frame a collector writes	right per-column reasoning, but it reads collector source only — it says what the frame IS, never who consumes it
ServerLocalReadFrameDisciplineTests (#3202)	Darling, Lite production .cs	de-skew on reads of one table	the right boundary, scoped to default_trace_events by design

The gap is exactly the diagonal: a column whose frame CollectorTimestampFrameTests knows, reaching a consumer none of the four inspects.

Why the frame cannot be keyed on the column name

The repo has already established this twice and both notes are worth keeping:

• StoreSqlClockDisciplineTests maintains AmbiguousFrameColumns = ["sample_time", "event_time", "last_execution_time"] — three names that are two frames across several tables each, with the evidence per table.
• CollectorTimestampFrameTests' own remarks record that its first cut was a store-wide "all naive timestamps are UTC" rule that would have forbidden the CPU collector's intentional local clock.

So a guard here must be scoped per (table, column), and the census has to be derivable rather than hand-declared or it rots.

The technique that already works

#3202's EveryAnnotationSourcesDeclaredFrame_MatchesItsOwnCollectorsQueryText derives the frame from the collector's own query text instead of trusting a declaration: this codebase writes alias = expression, so the right-hand side is the provenance. A column assigned from the XE @timestamp is UTC; one assigned from fn_trace_gettable's StartTime or a dm_exec_* / dm_tran_* DMV value is server-local. Critically, it fails when the provenance cannot be read rather than defaulting to UTC — "a frame nobody can read is the state the de-skew defects shipped in."

Run over the whole collector corpus that classifier already resolves the population: 66 CollectorColumnType.Timestamp columns, with 17 server-local columns reaching a consumer. It also finds its own blind spot honestly — BlockedProcessReportCollector's six and DmvBlockingSnapshotCollector.event_time have no T-SQL assignment at all (they are parsed from XML in C#, or stamped from context.CollectionTime), so those need a C#-side arm or an explicit per-column declaration with its evidence. That is the honest shape of the coverage, not a reason to skip them.

What to decide before writing it

1. One guard or two. The MCP payload boundary (ToString("o") into an anonymous object) and the WPF render boundary (ForDisplay / FormatServerClock / FormatServerTime getters) are different discriminators over different roots. Two focused scans probably beat one that has to understand both.
2. How the census is anchored. A floor and a ceiling per file, the way ServerLocalReadFrameDisciplineTests.KnownReaders does it — a bare total lets a Darling site vanish and a Lite one appear and still add up, which is the one-sided-port regression De-skew query_stats.creation_time before comparing it to the analysis window (Part of #2991) #2992 found nothing guarding against.
3. Sequencing. The guard must be red before the fixes and green after, per site. If it is written after the fixes land and passes on the first run, it has converted an open question into false confidence. That means it lands with or after MCP reads return 16 server-local timestamps unmarked, beside naive-UTC fields in the same payload (#3198's siblings) #3206 and Desktop clock frames are wrong in opposite directions in both SKUs, and each SKU is right where the other is wrong #3207, with the red run recorded.

Floors to pin so a broken glob cannot report a clean bill of health, measured on dev at e63a367e7: 131 ToString("o") sites across 27 files in Darling/PerformanceMonitor.Darling.Service/Mcp/; 66 collector timestamp columns; ServerLocalReadFrameDisciplineTests measured 713 production .cs files across Darling/ and Lite/.

Blocks on, or lands with, #3206 (MCP reads) and #3207 (desktop renders). Related: #3198, #3202, #2991/#2992, #2932.

[erikdarlingdata]

Claude posting for Erik Darling

The guard is in — #3220, merged to dev as 91c0a919ac78. Closing by hand; closing keywords resolve against main.

ConsumedTimestampFrameDisciplineTests derives the frame register from the collector catalog rather than a hand list, and inventories every current offender at set equality: 33 McpPayloadUnmarked, 22 DesktopRenderFrameMismatch, 2 DeSkewedAtRead, plus 19 MCP and 3 render sites declined with reasons and pinned. It fixes nothing — #3086's idiom — and the ratchet runs both ways, so a new offender reds and a fixed one reds until its row is deleted. That is what stops the inventory rotting into a permanent excuse list.

Two independent corroborations worth recording. Every verdict the repo already had an opinion about agrees with it — CollectorTimestampFrameTests on both sample_time columns, #3202 on default_trace_events.event_time, #2991/#2992 on query_stats.creation_time. And the derived frame-ambiguous name set came out as exactly {event_time, last_execution_time, sample_time}, identical to StoreSqlClockDisciplineTests.AmbiguousFrameColumns — which was hand-written, for a different hazard. A derivation reproducing a hand list nobody consulted is the strongest evidence available that the derivation is right.

Three things this issue got wrong, all mine

The unreadable-provenance hole is 9 columns, not 7. query_store_stats.first_execution_time and last_execution_time are also unreadable from T-SQL: Query Store returns datetimeoffset and the stored frame is decided by ((DateTimeOffset)…).UtcDateTime in C#. That is precisely the fact #3207's sites 3-5 turn on, so the two missing columns were the ones most load-bearing elsewhere.

The T-SQL classifier reaches 49 columns, not 66. The other 17 are PostgreSQL, where no column = expression form exists and normalisation has four spellings including runtime-interpolated fragments. Counted and labelled rather than omitted.

"17 server-local columns reaching a consumer" was not a column count, and the number agreeing with anything was a coincidence of units. Derived independently it is the count of distinct MCP payload field names; as store columns it is 25; as sites, 33 MCP and 22 render. I quoted a figure without its unit and it happened to match a different quantity, which is the least detectable way to be wrong.

Two line numbers were also off: the projection disclaimer is at :42-46, not :43-47, and ViewerDataService.RunningJobs.cs's ForDisplay(StartTime) is at :135, not :117.

What the census hands the sibling issues

#3207 is missing 8 render sites, every one a one-sided port where Darling is correct and Lite is not: LocalDataService.QueryStats.cs (creation_time ×2, cached_time ×2 — the read de-skews only the window bound and returns the raw local value) and LocalDataService.PlanCorrection.cs:206-209 (×4). Two of #3207's own eight sit outside a catalog-derived census and stay outside: LastTranStarted is parsed from stored deadlock_graph_xml at read time, so no CollectorColumn declares it.

#3206 is missing a 17th field: Lite/Mcp/McpPlanCacheSchedulerTools.cs's oldest_plan_create_time, Lite-only. PR #3212 does not touch that file, so it survives that PR — and #3212's TheTwoSkus_DeSkewTheSameNumberOfFields still passes, because the asymmetry is in what remains rather than in what is fixed. A parity pin counting fixed fields cannot see an unfixed one.

Sequencing: 32 of the 33 MCP inventory rows are #3212's to delete as it fixes them. The two PRs are coupled through the set-equality ratchet.

Where the lane departed from this issue, correctly

This issue asked for red-before-fix per site. The lane substituted the two-way ratchet plus a 25-mutation matrix, on the ground that #3207's fix list depends on this census — sequencing the other way means deriving the list twice, by hand first. #3206 and #3207 each get their per-site red run when they fix a site and leave its row behind.

Three of the lane's own pins were vacuous on the first attempt, and the matrix rather than review is what found them: a boundary pin built on a prefix pair that is not one, a reachability check whose exemption list hid two genuinely dead vocabulary entries, and an alias pin written over a retyped copy of the pattern instead of the production regex. The negative control is calibrated in both directions — raising the judged-render floor with nothing planted reds, and planting a correctly framed site then makes it pass with the offender set unchanged.

Left open deliberately

cpu_utilization_stats.sample_time may carry two frames: the ring-buffer arm is SYSDATETIME() while the Azure arm ships sys.dm_db_resource_stats.end_time, which Microsoft documents as UTC. Nothing in this repository establishes that, so dm_db_resource_stats was left out of the provenance vocabulary rather than encoding a guess. Not urgent — every reader de-skews — and it wants its own issue rather than a silent entry.