Preserve an instant and its evidence
A programme guide can describe a broadcast time using a date, clock reading and offset. Your importer needs a consistent way to compare instants while retaining what the source actually supplied. Store the original value alongside the normalised instant, and keep the display timezone as a separate choice.
XMLTV specifies a default when its timezone information is omitted: UTC. That is a format rule, not a request to borrow the preparation computer's current local timezone. If a source appears to use another convention, record the conflict and resolve it with the source owner.
Do the arithmetic explicitly
For an invented listing at 20:30 with offset +0200, subtract two hours to obtain 18:30 UTC. Displaying that instant in another zone is a later operation. Repeatedly adding an offset to an already converted value is a common way for a pipeline to produce a plausible but wrong schedule.
Give every field a clear role: source clock, source offset, normalised instant and display label. Do not use one ambiguous time column for all four. A local clock string without context is inadequate when programmes cross midnight or a clock change.
Review repeated and skipped hours
An offset can distinguish two occurrences of the same local clock reading. In a hypothetical repeated hour, 01:30 +0200 and 01:30 +0100 are different instants one hour apart. The example is arithmetic, not a statement that a named country changes clocks at that exact time.
Prepare fixtures for midnight, an explicit offset change, missing zone data and a boundary between programmes. Verify that sorting follows instants and that display retains enough context to avoid confusing repeated labels. Do not make the fixture depend on the machine's current timezone.
Keep display and access separate
A correctly normalised schedule does not establish the live programme's actual start or replay entitlement. Preserve updates from the authoritative schedule source and make the import revision traceable. A display offset setting in a player is a separate layer from your stored guide data.
When correcting a conversion, revisit the affected interval and adjacent programmes. Record whether the change was source data, importer interpretation or display formatting. That distinction prevents a local display fix from being applied twice during the next import.
Questions answered
Should an absent XMLTV timezone use my computer's timezone?
No. XMLTV's documented default is UTC; any source-specific conflict needs evidence.
Can one clock label describe two different instants?
Yes. Preserve an explicit offset or equivalent unambiguous time representation.
Sources & further reading
Official references for the subjects discussed. Service terms and device software can change.