clock-sweeplisted

# clock-sweep Time bugs are the quietest bug class in software: nothing crashes, tests pass on the author's machine, and the wrong answers look right — until a user in another timezone, a DST transition, or a date boundary at midnight UTC exposes them. And they're rediscovered twice a year, every year. The root cause is almost always the same category error: treating **instants** (a point on the global timeline), **wall-clock times** (what a clock on a wall in some place reads), and **calendar dates** (no time at all) as interchangeable. The audit finds every place the code blurs them. ## The three types — get this straight first - **Instant**: "the meeting started" — a global point. Store as UTC (ISO-8601 with offset, or epoch). Timezone is a *display* concern. - **Future wall-clock time**: "9:00 on March 14 in Istanbul" — NOT an instant, because the zone's rules can change between now and then. Store as local time + IANA zone name (`Europe/Istanbul`), never as a precomputed UTC instant and never with a fixed offset (`+03:00` is a fact about one moment, not a place). - **Calendar date**: "born 2011-05-02" — has no timezone. Storing it as midnight-anything makes it shift a day for half the planet. Keep it a date type end-to-end. Most bugs are one sentence long when named: "this stores a future wall-clock time as a UTC instant", "this treats a date as an instant". ## The sweep Grep the whole surface, not the file the bug was reported in — the same mistake repeats whereve