Open SteveLLamb opened 2 years ago
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?
Have you tried 2012-07-14T21:52:02Z, which indicates a UTC timestamp?
Yes, this also does not work.
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.
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>
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.
@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>
Can I ask about a timestamp ending in +00:00
? The -00:00
is technically incorrect.
Can I ask about a timestamp ending in
+00:00
? The-00:00
is technically incorrect.
Also does not work.
Also does not work.
Okay, thanks for checking.
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.
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)
Just for clarification, is the mention of z
a typo for Z
?
Just for clarification, is the mention of
z
a typo forZ
?
Updated comment. Yes.
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)?"/>
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
?
"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.