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.
Keep the evidence dates separate
A guide workflow can record when its source was produced, when it was fetched and when a local conversion ran. Those are different events. If a file was generated this morning, that timestamp alone does not prove its programme information was updated this morning. Preserve the original source context alongside processing records.
Read the root-date guidance
XMLTV’s DTD comments describe the tv root date as the date the listings were originally produced and say a conversion should retain the source’s date rather than substitute the conversion time. This is a provenance distinction. It should not be confused with the date element inside a programme, which describes another property of that work.
Apply a hypothetical processing sequence
Suppose listings produced onMonday are fetched onTuesday and converted onWednesday without new programme data. Wednesday accurately describes the conversion event, while it would overstate source freshness if displayed as the schedule’s update date. A consumer can show those dates separately, with clear labels, instead of choosing the newest timestamp for every purpose.
Check coverage as well as age
Inspect whether the actual schedule includes the intended dates and broadcaster edition. A recent source timestamp does not by itself prove completeness or accuracy, while an older timestamp does not reveal every missing item without examination. This article explains date provenance and a hypothetical workflow; it reports no UK IPTV schedule update, automated refresh or observed feed freshness.