Issue 0096 date time #288
Issue 0096 date time #288
Conversation
There was a problem hiding this comment.
I am requesting some changes before this is merged. Since it has already been merged, I am requesting that it be unmerged, requested changes to be applied and the updated branch with the changes to be merged when consensus has been achieved.
The early merge here was unhelpful and unnecessary in my view.
| : date "T" wall-time | ||
|
|
||
| wall-time | ||
| : ( hhmm-time | hhmmss-time ) |
There was a problem hiding this comment.
This is missing a (TZD)? component.
| @@ -16886,6 +16908,8 @@ when the <code>clock</code> time base applies.</p> | |||
| <p>If a <time-expression> is expressed in terms of an | |||
| <emph>offset-time</emph> and no <emph>metric</emph> is specified, then it is to be treated as | |||
| if a metric of <code>s</code> (seconds) were specified.</p> | |||
| <p>It is considered an error if the <emph>wallclock-time</emph> form of a <time-expression> | |||
| is used in a <loc href="#terms-document-instance">document instance</loc> and the government time base is not <code>clock</code>.</p> | |||
There was a problem hiding this comment.
s/government/governing
?
| @@ -22464,29 +22512,30 @@ as follows: | |||
| </sitem> | |||
| <sitem/> | |||
| <sitem> | |||
| (1) if <code>local</code>, then the difference between the local real time at the most immediately prior local midnight and the local real time | |||
| (1) if <code>local</code>, then the difference between the local real time at the most immediate prior local midnight and the local real time | |||
There was a problem hiding this comment.
NB it is not possible to infer anything from this which definition of 'local' applies - this does not need changing in my view but does point to why the (TZD)? component needs to be available in wallclock time expressions.
There was a problem hiding this comment.
The definitions of epoch when local applies and C seem to conflict. It seems to me that the date part of a wallclock time defines the epoch and the applicable midnight to use and the C is just an interpretation of the time part of the expression relative to that epoch.
|
There is no need to unmerge to affect changes. Further, there is already a
discussed and agreed status. Please create a new issue listing any new
changes requested, and I will process ASAP.
…On Thu, Apr 13, 2017 at 5:23 AM, Nigel Megitt ***@***.***> wrote:
***@***.**** commented on this pull request.
I am requesting some changes before this is merged. Since it has already
been merged, I am requesting that it be unmerged, requested changes to be
applied and the updated branch with the changes to be merged when consensus
has been achieved.
The early merge here was unhelpful and unnecessary in my view.
------------------------------
In spec/ttml2.xml
<#288 (comment)>:
>
clock-time
: hours ":" minutes ":" seconds ( fraction | ":" frames ( "." sub-frames )? )?
offset-time
: time-count fraction? metric?
+wallclock-time
+ : "wallclock(" <loc href="#style-value-lwsp"><lwsp></loc>? ( date-time | wall-time | date ) <loc href="#style-value-lwsp"><lwsp></loc>? ")"
+
+date-time
+ : date "T" wall-time
+
+wall-time
+ : ( hhmm-time | hhmmss-time )
This is missing a (TZD)? component.
------------------------------
In spec/ttml2.xml
<#288 (comment)>:
> @@ -16886,6 +16908,8 @@ when the <code>clock</code> time base applies.</p>
<p>If a <time-expression> is expressed in terms of an
<emph>offset-time</emph> and no <emph>metric</emph> is specified, then it is to be treated as
if a metric of <code>s</code> (seconds) were specified.</p>
+<p>It is considered an error if the <emph>wallclock-time</emph> form of a <time-expression>
+is used in a <loc href="#terms-document-instance">document instance</loc> and the government time base is not <code>clock</code>.</p>
s/government/governing
?
------------------------------
In spec/ttml2.xml
<#288 (comment)>:
> @@ -22464,29 +22512,30 @@ as follows:
</sitem>
<sitem/>
<sitem>
-(1) if <code>local</code>, then the difference between the local real time at the most immediately prior local midnight and the local real time
+(1) if <code>local</code>, then the difference between the local real time at the most immediate prior local midnight and the local real time
NB it is not possible to infer anything from this which definition of
'local' applies - this does not need changing in my view but does point to
why the (TZD)? component needs to be available in wallclock time
expressions.
------------------------------
In spec/ttml2.xml
<#288 (comment)>:
> @@ -22464,29 +22512,30 @@ as follows:
</sitem>
<sitem/>
<sitem>
-(1) if <code>local</code>, then the difference between the local real time at the most immediately prior local midnight and the local real time
+(1) if <code>local</code>, then the difference between the local real time at the most immediate prior local midnight and the local real time
The definitions of epoch when local applies and C seem to conflict. It
seems to me that the date part of a wallclock time defines the epoch and
the applicable midnight to use and the C is just an interpretation of the
time part of the expression relative to that epoch.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
<#288 (review)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAXCb9gpg1q0dxjyid66e66sbXpqdhb7ks5rvgW3gaJpZM4M8Wxo>
.
|
|
I have some heartburn here. What happens with For reference, see https://www.w3.org/TR/timezone/ |
|
I originally included a timezone component in the wallclock-time expression
in order to align with SMIL 3.1. However, I soon realized that this would
be at odds with the fact that a fixed ttp:clockMode already implies a
specific time zone. In the case of 'local' clock mode, it effectively means
whatever time zone applies to the document processing context (not the
authoring context). Adding a timezone component in this case would only be
confusing and cumbersome. The same applies with 'utc' clock mode.
The only question that remains in my mind is whether we should allow the
optional use of a 'Z' timezone component when clock mode is 'utc'.
…On Thu, Apr 13, 2017 at 9:33 AM, Addison Phillips ***@***.***> wrote:
I have some heartburn here. What happens with ttp:clockMode when its
value is local? A local time offset (LTO) is not a good definition of a
time zone and the syntax here doesn't permit the expression of the LTO in
any case. Are local time zone rules expected to apply to the date and time
values? If not, how do "local" times work?
For reference, see https://www.w3.org/TR/timezone/
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
<#288 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAXCbwkdfXFcFeh8-UCyeMKM-oU0zJ0Xks5rvkA5gaJpZM4M8Wxo>
.
|
As stated on the pull request review comments I would like to reintroduce the optional
I don't agree.
That would be of no benefit that I can determine. |
|
On Thu, Apr 13, 2017 at 10:27 AM, Nigel Megitt ***@***.***> wrote:
In the case of 'local' clock mode, it effectively means
whatever time zone applies to the document processing context (not the
authoring context)
As stated on the pull request review comments I would like to reintroduce
the optional (TZD)? component so that it can be defined in the authoring
context, which seems like a reasonable thing to want to do. Also note that
one use case for this is when the generated document is an archive of what
was actually created, rather than a document intended for later
presentation. In the case of live subtitles this is an important use case,
and it is reasonable to record the time zone in this use case.
While I do not take any position on this possible use case, it has not been
articulated previously (AFAICT). Further, it is a significant departure
from the use of time expressions in TTML to specify intended presentation
time, and not recorded time. As such, I question whether we should be
considering such use case in the present context, namely the use of time
expressions in TTML as presently the case.
One can imagine introducing metadata items to be used in recording time
stamps, and one can imagine that timezone data may be useful there, but to
conflate this usage with an interpretation of time expressions that are
based on ttp:timeBase and ttp:clockMode is over-reaching in the context of
this issue.
… Adding a timezone component in this case would only be
confusing and cumbersome.
I don't agree.
The only question that remains in my mind is whether we should allow the
optional use of a 'Z' timezone component when clock mode is 'utc'.
That would be of no benefit that I can determine.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
<#288 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAXCb2IdPL0QABNYfL7zseoY99jZ1ZA1ks5rvkzbgaJpZM4M8Wxo>
.
|
In fact it was articulated back in October 2014: https://www.w3.org/2014/10/27-tt-minutes.html and in general the use case was mentioned in https://www.w3.org/wiki/TTML/changeProposal025 Certainly there has never been any text in the spec that constrains the times to be in the future, and I have always read it that the times may either be historical or future-based, especially when Further, there is implementation work that creates TTML documents based on historical events already, using exactly this approach. |
|
Thanks for the pointer. I will review. At first glance, supporting this
mode would require introducing a new clockMode value, say 'archive', which,
if used, would permit the use of timezone information.
…On Thu, Apr 13, 2017 at 10:55 AM, Nigel Megitt ***@***.***> wrote:
it has not been articulated previously (AFAICT)
In fact it was articulated back in October 2014:
https://www.w3.org/2014/10/27-tt-minutes.html and in general the use case
was mentioned in https://www.w3.org/wiki/TTML/changeProposal025
Certainly there has never been any text in the spec that constrains the
times to be in the future, and I have always read it that the times may
either be historical or future-based, especially when ttp:timeBase="clock".
So it is not at all a significant departure but a natural consequence of
the language already present (and absent) from the specification.
Further, there is implementation work that creates TTML documents based on
historical events already, using exactly this approach.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
<#288 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAXCb_y41b9OGKtzusDQ9OS5m4er5quTks5rvlNpgaJpZM4M8Wxo>
.
|
I would say no such change is needed - if anything the fact that the times are archive times is a matter of metadata rather than the times themselves. I have not found anything other than time zone that cannot be done with the spec as it is when creating archived recordings of live subtitles, so I would do as little as possible here. |
|
The problem is that using a wall clock time with explicit time zone in
either clock mode local or utc doesn't make any sense, unless you ignore
the meaning of local and utc. That is, IMO, a time expression that attempts
to express a time outside of the local time system while saying it uses the
local time system is not well formed, and similarly for utc.
…On Thu, Apr 13, 2017 at 11:12 AM, Nigel Megitt ***@***.***> wrote:
At first glance, supporting this
mode would require introducing a new clockMode value, say 'archive', which,
if used, would permit the use of timezone information.
I would say no such change is needed - if anything the fact that the times
are archive times is a matter of metadata rather than the times themselves.
I have not found anything other than time zone that cannot be done with the
spec as it is when creating archived recordings of live subtitles, so I
would do as little as possible here.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
<#288 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAXCb4FQAB4rejBt3TxtSFbkRwb0eCEzks5rvldkgaJpZM4M8Wxo>
.
|
|
@skynavga All time values need to become incremental times measured on the system's epoch-based timekeeping system (monotonic time measured using integers) for processing purposes. Otherwise you can't really do anything. Time zones (or LTO if that's all you have) can be used as part of the process of converting the time fields into the incremental representation. A wall clock time Does that make sense? |
Add wallclock-time form for time-expression syntax, allowing explicit dates; however, do not support explicit time zone offsets since
ttp:clockModealready implicitly selects time zone that applies to time expressions.Add #time-wall-clock feature designator.
See #96.