Preserve XMLTV timestamp precision when importing listings

The useful distinctions

• XMLTV date strings can use an initial substring of YYYYMMDDhhmmss.
• An explicit timezone may follow the digits.
• The DTD documentation defines UTC when no timezone is supplied.

Keep precision as data

The programme start in the sample identifies a complete second and an explicit numeric offset. The date element supplies only a year and month for production. These values answer different questions and should not be run through a single conversion that silently appends day one and midnight. A practical import row can keep original_text, precision, and parsed_value separately. Where the precision is only a month, parsed_value might be a month object or an explicitly labelled interval, depending on the receiving system.

Validate structure before calendar arithmetic

The DTD declares these attributes as character data, so passing DTD validation does not prove that a timestamp is a real calendar value. A semantic check must still reject impossible days, malformed offsets, and unsupported abbreviations. Prefer an explicit numeric offset in newly authored interchange examples because its interpretation can be inspected directly. If an importer expands an incomplete date to a full instant for database storage, retain a flag showing that the extra fields were invented by policy. The same separation makes round trips more honest: exporting the stored midnight without the precision flag would imply knowledge the original record never supplied. This is an interchange-data concern, not a viewer clock-setting procedure.

Worked example · synthetic

The start has second precision and corresponds to 09:00 UTC; the stop is thirty minutes later. The production date means October 2026 at month precision, not an asserted production instant.

Synthetic text example; no network operation has been performed.

<tv>
  <programme start="20261108140000 +0500" stop="20261108143000 +0500" channel="workshop.example">
    <title>Paper Lanterns</title>
    <date>202610</date>
  </programme>
</tv>

Check the interpretation

• Keep the original string and precision.
• Check calendar validity and numeric-offset ranges separately from the DTD.
• Do not infer a time of day from the production date.