#### 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](#exercise-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](#answer-ex019). 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-04-day-03) · [Week 4 index](#ch-04) · [Course index](../SUBJECTS.md) · [Next: Day 20](#week-04-day-05). ### 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](#answer-ex019). ## 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.