timestamp in MIDIEvent in odds with DOM4 Event timeStamp?

[jussi-kalliokoski]

Originally reported on W3C Bugzilla ISSUE-20411 Mon, 17 Dec 2012 14:26:23 GMT Reported by Jussi Kalliokoski Assigned to This bug has no owner yet - up for the taking

[ Marcos Caceres wrote ]

DOM4 Event defines: readonly attribute DOMTimeStamp timeStamp;

While MIDIEvent [1] defines timestamp: readonly attribute DOMHighResTimeStamp timestamp;

I think that is going to lead to confusion. Perhaps it might be worth talking to the WebIDL people and getting them to up the precision of DOMTimeStamp? Or easier to just rename the MIDIEvent attribute? Cameron, thoughts?

[jussi-kalliokoski]

Original comment by Jussi Kalliokoski on W3C Bugzilla. Mon, 17 Dec 2012 14:30:38 GMT

(In reply to comment #0)

[ Marcos Caceres wrote ]

DOM4 Event defines: readonly attribute DOMTimeStamp timeStamp;

While MIDIEvent [1] defines timestamp: readonly attribute DOMHighResTimeStamp timestamp;

I think that is going to lead to confusion. Perhaps it might be worth talking to the WebIDL people and getting them to up the precision of DOMTimeStamp? Or easier to just rename the MIDIEvent attribute? Cameron, thoughts?

Hmm, I doubt upping the precision of DOMTimeStamp makes sense for the use cases it serves. I think it's a better idea to rename the timestamp to something less ambiguous, but my best (and worst) idea for now is "MIDITimeStamp" (I have no preference on the casing), but that's not very appealing.

But I agree, it's confusing to have "timestamp" and "timeStamp" that may differ in times and in precision.

[jussi-kalliokoski]

Original comment by Marcos Caceres on W3C Bugzilla. Mon, 17 Dec 2012 15:53:05 GMT

I'm wondering if we can just override it.

[jussi-kalliokoski]

Original comment by Jussi Kalliokoski on W3C Bugzilla. Mon, 17 Dec 2012 15:58:38 GMT

(In reply to comment #2)

I'm wondering if we can just override it.

You mean not have the DOM "timeStamp" at all, and instead rename "timestamp" to "timeStamp"? Sounds good to me, if it's not against the rules or something. :D

[jussi-kalliokoski]

Original comment by Marcos Caceres on W3C Bugzilla. Mon, 17 Dec 2012 16:08:15 GMT

Certainly not against the rules. What I'm wondering is if there can be a difference between the MIDI's timestamp and the Event's timestamp.

However, the timeStamp generally refers to the time at which the corresponding event took place of the thing one is interested in (and not when the Event object was constructed). If that definition of timeStamp holds, then I don't see any problem with overriding timeStamp to have a high precision.

[jussi-kalliokoski]

Original comment by Jussi Kalliokoski on W3C Bugzilla. Mon, 17 Dec 2012 16:17:20 GMT

(In reply to comment #4)

Certainly not against the rules. What I'm wondering is if there can be a difference between the MIDI's timestamp and the Event's timestamp.

However, the timeStamp generally refers to the time at which the corresponding event took place of the thing one is interested in (and not when the Event object was constructed). If that definition of timeStamp holds, then I don't see any problem with overriding timeStamp to have a high precision.

Yes, that definition holds. Good!

[jussi-kalliokoski]

Original comment by Chris Wilson on W3C Bugzilla. Mon, 17 Dec 2012 19:21:36 GMT

(In reply to comment #5)

(In reply to comment #4)

Certainly not against the rules. What I'm wondering is if there can be a difference between the MIDI's timestamp and the Event's timestamp.

However, the timeStamp generally refers to the time at which the corresponding event took place of the thing one is interested in (and not when the Event object was constructed). If that definition of timeStamp holds, then I don't see any problem with overriding timeStamp to have a high precision.

Yes, that definition holds. Good!

Yes, that definitions holds, but is it really okay to redefine the timeStamp to a completely different type? The timestamps we have now are DOMHighResTimeStamps, which are a double representing time since navigation start; DOMTimeStamps are unsigned long longs representing (integer) milliseconds since 00:00:00 UTC on 1 January 1970.

receivedTime?

[jussi-kalliokoski]

Original comment by Marcos Caceres on W3C Bugzilla. Mon, 17 Dec 2012 19:55:27 GMT

receivedTime wfm. Both measures (relative and absolute) is kinda nice.

[jussi-kalliokoski]

Original comment by Chris Wilson on W3C Bugzilla. Mon, 17 Dec 2012 20:03:59 GMT

(In reply to comment #7)

receivedTime wfm. Both measures (relative and absolute) is kinda nice.

Hmm. You mean filling out timeStamp (in DOMTimeStamp format) as well as receivedTime (as a DOMHighResTimeStamp)? Sigh. Yeah, I suppose.

[jussi-kalliokoski]

Original comment by Marcos Caceres on W3C Bugzilla. Mon, 17 Dec 2012 20:07:27 GMT

(In reply to comment #8)

(In reply to comment #7)

receivedTime wfm. Both measures (relative and absolute) is kinda nice.

Hmm. You mean filling out timeStamp (in DOMTimeStamp format) as well as receivedTime (as a DOMHighResTimeStamp)? Sigh. Yeah, I suppose.

Well, that kinda needs to happen regardless as it's part of the DOMEvent interface. I guess what we need to say in the spec is that it reflects the receivedTime to the nearest millisecond (rounded or floored?).

[jussi-kalliokoski]

Original comment by Chris Wilson on W3C Bugzilla. Mon, 17 Dec 2012 20:22:13 GMT

(In reply to comment #9)

Well, that kinda needs to happen regardless as it's part of the DOMEvent interface. I guess what we need to say in the spec is that it reflects the receivedTime to the nearest millisecond (rounded or floored?).

Well that's the annoying part - since it's a completely different timeframe, it's a long conversion. At least it's not on another hardware clock, like audio.

I'd suggest floored, but I think it's mostly irrelevant - I'd rather advise against using timeStamp, due to precision. I wish it weren't there.