Keep capture context separate from clock arithmetic

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Public activity · 30d

—Participating browsers

—Page views

—Reading sessions

—Exercise opens

Counts reflect browsers that allowed analytics. A reading session requires 30 seconds on a visible page. Browsers are not people.

Day 19 — Keep capture context separate from clock arithmetic

Theory and mechanism. Time normalization changes an interpreted representation; it does not authenticate the time source. An image can contain several clocks: a rendered application time, device clock, filename or metadata timestamp. Receipt time records when the case obtained an item. None must be silently substituted for capture time or for the time a business state changed. A reliable annotation preserves the raw display, claimed zone/offset, conversion method, time-source confidence and separate receipt.

For C10, the given arithmetic is 11:21 − 02:00 = 09:21 UTC, conditional on the displayed fixed offset and clock. The case receipt is 09:22. Subtraction alone cannot show that the picture was captured exactly one minute before receipt: its capture-device clock and the semantics of the displayed time are unverified. Nor does that interval measure the duration of the unavailable state. Keep the screenshot observation and the authoritative-state question separate.

Worked contrast. Caption A says “S42's database became unavailable at 09:21; evidence collected a minute later.” It invents the authoritative state, transition time and collection latency. Caption B says “Support supplied an image at 09:22 showing S42 unavailable and a display reading 11:21 UTC+02:00; the conditional conversion is 09:21 UTC, while capture time, cache and backend state remain unverified.” B permits the next investigator to question each assumption without discarding the report.

At the professional level, a context request should be specific: preserve the original image file and ticket under permitted access; ask which device/application clock is shown, what establishes its offset, which page and authorized role/view produced the display, whether a refresh/cache distinction is known, and whether a minimal request/version identifier can be linked to an application-side record. A full screenshot of unrelated learner records is not needed to ask those questions. If a redacted view is shared, record it as a derivative and preserve the actual source access boundary.

Independent contrast exercise, W4-CLOCK. Suppose another training picture displays the same digits, 11:21, but its stated fixed offset is +03:00. The conditional conversion is 08:21 UTC, one hour earlier than C10's +02:00 conversion. That difference comes from an explicitly changed assumption; it is not a correction to canonical C10. If the offset is absent, the correct result is UTC estimate unavailable without another time basis, not a guess based on the analyst's laptop timezone. If a screenshot is re-encoded, its new file metadata likewise cannot prove the original capture time. These variants require no source connection or real personal image.

Decision and limit. Retain C10 as bounded evidence of a displayed symptom. A requested authoritative S42 value/version and read time could clarify current state at the time of that permitted read. It would not automatically reconstruct the historical backend state at 09:21; historical claims need their own traceable records and clock semantics. Do not let a later current-state check rewrite an earlier screenshot caption.

Practice. Complete EX019 with the raw/derived/receipt fields, the two captions' evidential difference and one bounded context request. Explain W4-CLOCK without importing its offset into C10, then compare the worked answer. An accurate conversion is necessary for the supplied arithmetic task but insufficient for a capture-time or state claim.

Continue studying — course Day 19: Previous: Day 18 · Week 4 index · Course index · Next: Day 20.

Exercise for this lesson

EX019 — Timezone annotation. Objective: normalize a displayed time without authenticating capture or state. Input: C10, Day 19 and its explicitly separate W4-CLOCK variant. Record raw 11:21 UTC+02:00, conditional UTC conversion and 09:22 receipt separately. Explain why their difference is not a measured capture-to-receipt latency or backend transition time. Give a bounded context request, the +03:00 variant result and the outcome if no offset is supplied. Rubric: 0 = wrong sign, asserted capture clock or authoritative state; 1 = conditional 09:21 but incomplete context/variant reasoning; 2 = correct distinct time fields, source-limited caption, variant distinction and targeted request. Worked answer.

Practice the exercises

Open a prompt, write your response, then compare it with the worked answer. Five-choice practice appears where a reviewed question is available.

EX019

Open the prompt →Compare with the worked answer →

Opens in 30 days: — · browsers: —

Checking for a reviewed five-choice question…

Worked answers

EX019 — Model time annotation. The screenshot's displayed 11:21 with a fixed UTC+02:00 label converts to 09:21 UTC after subtracting two hours; the support desk received it at 09:22 UTC. Record raw display, stated offset, conditional conversion and receipt in separate fields. Without capture-device clock evidence and cache context, do not claim that the authoritative S42 state changed at 09:21 or that every viewer saw the same result.

Additional worked reasoning (EX019 — Conditional screenshot time.): 11:21 at an asserted UTC+02:00 offset corresponds to 09:21 UTC. C10 entered the case at 09:22, not at 09:21. Without evidence about capture-device clock accuracy, page freshness and source state, label the conversion conditional and the symptom a screenshot observation. No current backend S42 value is established by the picture.

Week 4 Day 19 — worked context annotation. Raw display: 11:21 UTC+02:00. Conditional displayed UTC: 09:21 after subtracting two hours. Case receipt: 09:22. Clock/offset verification, capture time, page cache and authoritative S42 state: not supplied. The nominal one-minute difference is not measured transfer latency because the display has not been established as an accurate capture clock. A safe caption attributes the picture to support and retains the uncertainty. A bounded request seeks the original image/ticket under permitted access, displayed-clock semantics, device time basis, page/role/cache context and minimal request/version pointers if available. W4-CLOCK's separate +03:00 assumption yields 08:21 UTC; with no offset or another trustworthy time basis, a UTC estimate is unavailable. Do not change C10 to match either variant. A later current-state read answers a new observation at its own read time, not automatically the historical 09:21 state.