XMLTV / worked schedule interpretation · Primary-source explanation; no UK IPTV implementation or account test. Instructions are based on publisher guidance; a UK IPTV account was not tested on this platform.
Record the baseline interpretation
Suppose a source supplies a programme at20:00 with offset+02:00. The corresponding UTC instant is18:00. Keep that original value and determine what the legitimate player already does with its timezone information. A manual EPG correction should not be introduced solely because the source’s clock label differs from the user’s local clock.
Calculate the double-adjustment case
In a hypothetical faulty workflow, an importer first subtracts two hours correctly to obtain18:00 UTC, then another layer subtracts the same two hours again and reaches16:00. The second subtraction has moved the instant, rather than merely choosing another label for it. This example illustrates the arithmetic consequence; it does not assert how any specific player implements its controls.
Use one known programme as a reference
Choose an identifiable scheduled item and compare its actual source timestamp, the consumer’s timezone setting and the displayed result. Change one documented setting at a time. A problem affecting every title by a fixed interval differs from a guide mapped to the wrong channel edition, where the titles themselves can be wrong even if the clock arithmetic is correct.
Keep source and correction visible in support
Report which conversion was performed by which stage, or state that the stage is unknown. Preserve the original before changing it. Adding offsets at several layers makes a later support discussion harder because the visible number no longer reveals the starting value. This article provides a worked diagnostic model, not an observed UK IPTV bug or a universal EPG setting.