Constraint on xs:dateTime for IssueDate (428-7)

[SteveLLamb]

"Long" xs:dateTime used in IssueDate has been found to cause playback failure on Series 1 rendering of 428-7 TimedText (as shown in example of 428-7, as below):

<dcst:IssueDate>2012-07-14T21:52:02.000-00:00</dcst:IssueDate>

This has been confirmed by at least 1 manufacturer of TimedText rendering solutions. Suggest adding in constraint for "short" xs:dateTime:

<dcst:IssueDate>2012-07-14T21:52:02</dcst:IssueDate>

Confirmed to work on all systems, including Series 1.

[palemieux]

2012-07-14T21:52:02 is misleading since it indicates a local time, the timezone of which is unknown,

Have you tried 2012-07-14T21:52:02Z, which indicates a UTC timestamp?

[SteveLLamb]

Have you tried 2012-07-14T21:52:02Z, which indicates a UTC timestamp?

Yes, this also does not work.

[palemieux]

In addition to the constraint, it would be good to have a note that warns implementers and authors that the IssueDate is not in UTC but instead in an undefined local time.

[SteveLLamb]

This is my draft wording for this constraint:

---

IssueDate

XML datatype xs:dateTime as represented in IssueDate within Timed Text DCDM, as defined in ST 428-7, shall conform to undefined local time; UTC shall not be used. It shall be represented as:

CCYY-MM-DDThh:mm:ss

NOTE: For the purposes of this document, as an example, the IssueDate shall be in this format:

<dcst:IssueDate>2012-07-14T21:52:02</dcst:IssueDate>

[palemieux]

Suggested tweak:

The value of the IssueDate element shall conform to the following syntax: yyyy-mm-ddThh:mm:ss.

NOTE: the IssueDate element is expressed in an unspecified local time, and not in UTC.

[SteveLLamb]

@palemieux thanks for the suggestion. How about this? I want to leave the datatype part, so it's known it's still a valid datatype).

---

IssueDate

The value of the IssueDate element within Timed Text XML DCDM, as defined in ST 428-7, shall conform to the following syntax: yyyy-mm-ddThh:mm:ss.

NOTE 1: The IssueDate element is expressed in an unspecified local time, and not in UTC. This is still a valid XML datatype of xs:dateTime.

NOTE 2: For the purposes of this document, the below shows an example representation:

<dcst:IssueDate>2012-07-14T21:52:02</dcst:IssueDate>

[msheby]

Can I ask about a timestamp ending in +00:00? The -00:00 is technically incorrect.

[SteveLLamb]

Can I ask about a timestamp ending in +00:00? The -00:00 is technically incorrect.

Also does not work.

[msheby]

Also does not work.

Okay, thanks for checking.

[SteveLLamb]

Also does not work.

Okay, thanks for checking.

Appears that while it was throwing a logging error, doesn't result in subs not rendering. I will update the wording.

[SteveLLamb]

Summary of findings, and we need a regex for this at this point.

Works: <dcst:IssueDate>2012-07-14T21:52:02</dcst:IssueDate> OR <dcst:IssueDate>2012-07-14T21:52:02+00:00</dcst:IssueDate>

Does not work: <dcst:IssueDate>2012-07-14T21:52:02Z</dcst:IssueDate> OR <dcst:IssueDate>2012-07-14T21:52:02.000-00:00</dcst:IssueDate>

(any representation with Z or .xxx or negative TZ offset results in playback error and does not render)

[msheby]

Just for clarification, is the mention of z a typo for Z?

[SteveLLamb]

Just for clarification, is the mention of z a typo for Z?

Updated comment. Yes.

[msheby]

Freestyle attempt 6 with no need to fix the numerical semantics (thank you O'Reilly Media): <xs:pattern value=".+T\d{2}:\d{2}:\d{2}(\+00:00)?"/>

[msheby]

I'm sorry to even raise this, but please bear with me. With that initial example of 2012-07-14T21:52:02.000-00:00, there are two potential issues: (1) fractional seconds and (2) a pedantically invalid time-zone designator.

Were examples such as 2012-07-14T21:52:02-02:00 and 2012-07-14T21:52:02+02:00 also tested (i.e., integer seconds with straight-forward non-Zulu timezones) and they're just not mentioned here? Exotic but legal offsets like 2012-07-14T21:52:02+13:59?