Key takeaway
Formatting a timestamp cannot recover a missing offset. Keep unresolved local times out of calculations that require a unique instant.
Distinguish a clock reading from an instant
A service log can contain “01:30” twice during a backward clock change. It can also record a date with no time, a server time in UTC, and a technician’s local entry in the same export. Treating all of them as equally precise instants can reverse an event order or invent a duration. The first review asks what the source actually captured, before converting anything.
RFC 3339 defines an interchange timestamp including a numeric offset or Z. RFC 9557 distinguishes a time zone’s rules from a fixed offset and explains why a local time can have zero or multiple corresponding instants. Preserve the original string, source zone evidence, offset if recorded, precision and the interpretation rule as separate information.
A hypothetical ambiguous-time ledger
Consider a fictional log from a site whose clock is assumed to change from UTC−04:00 to UTC−05:00 on 1 November 2026. The calendar date and transition are invented scenario inputs, not a statement of an actual site’s clock rules. Both offsets can accompany the 01:30 local reading on that date. No conversion is permitted for the row whose offset remains unknown.
An analyst should retain the uncertainty instead of selecting whichever offset produces a plausible repair duration. That plausible answer could then be mistaken for the system’s original event time.
| Source value | Evidence | UTC interpretation | Permitted comparison |
|---|---|---|---|
| 2026-11-01 01:30; offset −04:00 | Offset recorded for this event | 2026-11-01 05:30 UTC | Unique instant within stated precision |
| 2026-11-01 01:30; offset −05:00 | Offset recorded for this event | 2026-11-01 06:30 UTC | Different instant, one hour later |
| 2026-11-01 01:30; offset absent | Site has backward transition | Unresolved: at least two candidates | Do not calculate exact elapsed time |
| Date only | No clock time captured | No unique instant | Use date-level coverage only |
A parser setting is not historical evidence
Python’s zoneinfo documentation demonstrates the fold attribute for choosing between two occurrences of an ambiguous local time. The available zone database supplies the relevant rules. Choosing fold zero or one solves a representation problem only after the source facts justify that choice; it does not tell you which occurrence a clerk meant.
Record the time-zone database version or environment used for the conversion when reproducibility matters. Retain the source system’s configuration history where it can be legitimately kept. A migration may have converted some fields while leaving others local. Test fields independently around representative transition boundaries rather than applying the current site setting to every historical row.
Give each duration a valid pair of endpoints
Identify whether endpoints are occurrence time, entry time, approval time or export time. Two well-formed timestamps can still measure the wrong interval. A repair duration needs the relevant start and end events; a clerical delay needs occurrence and entry. Keep that business meaning in the dictionary beside the conversion rule.
Check precision before reporting a result. Two date-only values do not justify a minute-level claim. Two minute-rounded readings do not establish second-level ordering. If a source can only bound an event to an interval, describe that interval and choose a comparison that remains valid under the uncertainty. Do not invent seconds by filling them with zero and then call the value precise.
Release a bounded interpretation
In this scenario, the first two rows support distinct UTC instants; the third remains unresolved; the fourth supports only a calendar-date description. The package documentation states those limits and keeps the original representations. A recipient can then select records suitable for duration analysis rather than discovering the ambiguity after a model or report has been evaluated.
Use readiness to assign configuration questions to the system owner and inventory to state the actual timestamp coverage. If exact time or location could identify a person, its release remains a separate privacy and purpose decision. This clock review improves interpretation; it does not establish that a timestamp may be shared or that later information was available at an earlier prediction point.