## TL;DR
Dedupe usually keys on a natural id plus the event time, and if that time was parsed as local time when it was really UTC, or converted twice, the same event produces two different keys and survives as a duplicate, while distinct events can collapse into one. Establish the source timezone from evidence, not assumption: compare a known event against the source system, reparse the raw values with the correct zone into UTC, and rebuild the dedupe keys for the affected window.

```text
agent applied the wrong timezone to event timestamps, dedupe broke
```

## Use this when
- Duplicates appear, or real events vanish, right after a timestamp handling change in a load.
- The same event shows two timestamps a fixed number of hours apart.
- Dedupe worked in one environment and breaks in another with a different default timezone.

## Not for this skill when
- The duplicates share identical timestamps and ids. That is a repeated delivery problem, not a timezone problem.
- The source changed its own timezone reporting. Reconcile with the producer rather than reparsing blindly.

## Steps
1. Pick one event you can find in both the source and the warehouse and compare its raw timestamp text, the stored value, and the true time it happened. Note the offset between stored and true. Verify: the size and direction of the timezone error are measured on a real event
2. Decide the source zone from evidence: the source system setting, the raw format including any offset suffix, and the measured offset. Write the decision down with the event used. Note the declared source zone. Verify: the correct zone rests on a checked example, not a guess
3. Find every place the load parses or converts the timestamp and make it one explicit conversion: parse in the source zone, store in UTC, with no implicit defaults from the host or the session. Note the single conversion point. Verify: conversion happens once, explicitly, in code
4. Rebuild the dedupe keys for the affected window from the raw timestamps using the corrected conversion, and re-run dedupe, comparing counts against the source event count for the window. Note the reconciled count. Verify: duplicates from the bad window are removed and real events restored
5. Add a guard: a test that a known reference event lands at its expected UTC time, run in the load's checks, set the environment timezone explicitly in the job, and rerun the load. Note the guard passes. Verify: a future timezone slip fails a check instead of corrupting dedupe

## Variant phrasings
### timestamp parsed as local instead of UTC duplicate events dedupe
The parse assumption phrasing.
### event timestamps off by hours after timezone conversion etl
The offset symptom search.

Compatibility: Any ETL or agent load handling event timestamps into a warehouse, especially from files or APIs that send zone-less timestamp strings. Warehouse timestamp types with and without timezone behave differently; know which yours stores.

## Why it happens
A zone-less timestamp is an incomplete fact, and every tool in the chain will happily complete it with its own default: the parser's locale, the host's timezone, the warehouse session setting. Those defaults differ between a developer laptop, a CI runner, and a production worker, which is why the bug is environment shaped and intermittent. Dedupe exposes it because dedupe is an equality test; a value can be four hours wrong and still look plausible everywhere except in an equality comparison against the same event parsed the other way.

## Edge cases / pitfalls
- Daylight saving transitions make a fixed offset correction wrong for part of the year. Use a named zone with rules, not a numeric offset.
- Around the autumn clock change, one local hour happens twice. Zone-less local times in that hour are genuinely ambiguous; prefer the producer's UTC time if it exists anywhere in the payload.
- Storing timestamps with a zone type in the warehouse does not fix a wrong parse upstream. The damage happens at reading time.
- Other windows loaded by the same code carry the same error even if dedupe did not flag them. Rebuild by load version, not only by complaint.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_lkgz5iDa1K6DH8vgM-X7KQ