The parsing we have for DateTime follow RFC3339 Section 5.6. Internet Date/Time Format, but the HLS specification calls out specifically ISO8601, which is attempted to be clarified into an ABNF within Appendix A. Specifically, the text of EXT-X-PROGRAM-DATE-TIME is as follows:
The EXT-X-PROGRAM-DATE-TIME tag associates the first sample of a
Media Segment with an absolute date and/or time. It applies only to
the next Media Segment. Its format is:
#EXT-X-PROGRAM-DATE-TIME:<date-time-msec>
where date-time-msec is an ISO/IEC 8601 [ISO_8601] date/time
representation, such as YYYY-MM-DDThh:mm:ss.SSSZ. It SHOULD indicate
a time zone and fractional parts of seconds, to at least millisecond
accuracy. If no time zone is indicated, the client SHOULD treat the
time zone as UTC.
The "such as" is concerning, as it indicates that YYYY-MM-DDThh:mm:ss.SSSZ is not the only date-time-msec format allowed, but it provides no specifics on what limitations exist. At the very least, our parsing currently assumes that there MUST be a time zone; however, the specification clearly indicates that timezones may be omitted (at which point UTC should be assumed), so our parsing is at least that much broken.
The parsing we have for
DateTimefollow RFC3339 Section 5.6. Internet Date/Time Format, but the HLS specification calls out specifically ISO8601, which is attempted to be clarified into an ABNF within Appendix A. Specifically, the text ofEXT-X-PROGRAM-DATE-TIMEis as follows:The "such as" is concerning, as it indicates that
YYYY-MM-DDThh:mm:ss.SSSZis not the onlydate-time-msecformat allowed, but it provides no specifics on what limitations exist. At the very least, our parsing currently assumes that there MUST be a time zone; however, the specification clearly indicates that timezones may be omitted (at which point UTC should be assumed), so our parsing is at least that much broken.