ENERPLAIN / FIELD NOTES
The hour that happens twice
Two rows labelled 02:15 can represent different instants. Preserve the offset and the timestamp meaning before treating them as duplicates.
Start with the instant: a local clock label alone may be ambiguous. In this synthetic Warsaw example, 02:15 +02:00 and 02:15 +01:00 identify instants one hour apart.
One local label, two UTC instants
Our sample window crosses the autumn daylight-saving transition in Europe/Warsaw on 25 October 2026, according to the time-zone rules available when this note was checked. At the clock change, the local hour repeats.
| UTC instant | Warsaw local representation |
|---|---|
| 2026-10-25T00:15:00Z | 2026-10-25T02:15:00+02:00 |
| 2026-10-25T01:15:00Z | 2026-10-25T02:15:00+01:00 |
A duplicate detector keyed only by device ID and a bare 02:15 clock string would collapse different instants in this example. The integration must follow the source’s declared identity contract.
Preserve three different pieces of meaning
- The instant: for example, an RFC 3339 timestamp with
Zor an explicit numeric UTC offset. - The named time zone: for example,
Europe/Warsaw, when local reporting rules depend on it. A numeric offset is not a substitute for the zone’s changing rules. - The interval convention: whether the timestamp means interval start, interval end, observation time or ingestion time.
Our example uses interval-start labels and an end-exclusive window. An export labelled by interval end needs a different comparison rule; simply reusing a window query could move a boundary record.
Do not invent a missing offset
If a source supplies only ambiguous local timestamps, do not silently choose an offset. Ask for the source convention, a UTC export, a sequence field or another reliable disambiguator. Keep unresolved records visible until there is enough evidence.
Test the spring gap, the autumn repeated hour, ordinary days and boundaries relevant to the actual source. Recheck future time-zone rules when upgrading the runtime or comparing a newly governed period.
References and example
- IETF RFC 3339 — timestamp format and numeric offset conventions; published July 2002.
- IANA Time Zone Database — maintained time-zone rules; checked 7 September 2026.
Download the synthetic JSON or use the Markdown reference. The example is about timestamp interpretation; it is not an OEM compatibility claim.