timestamp -> timeStamp?

[domenic]

Spinning off from #122... other places on the web platform use "time stamp" or timeStamp when in API form. Most notably, https://dom.spec.whatwg.org/#dom-event-timestamp .

It's probably a good idea to stay consistent with the rest of the platform in this regard, and use timeStamp (or timeStampMicroseconds) instead of timestamp or timestepMicroseconds

[chcunningham]

I do think timestamp is more common, but changing for consistency SGTM. I'll block on resolution of #122 (hopefully soon).

[chrisn]

I note that Media Source Extensions uses timestamp, and Web Audio has AudioTimestamp, so I'd suggest lowercase timestamp would be consistent with the parts of the platform that handle audio and video.

[cwilso]

I would note neither of those places uses "timestamp" as a variable name - in MSE, it's "start" and "end" and "timestampOffset" (the best proof of your point). In WebAudio, AudioTimestamp is a type - but you would use "getOutputTimestamp()", so kinda similar, but usually times are "start" and "end" and the like. By contrast, though, the DOMEvent "timeStamp" attribute is used pretty much everywhere (because most things that have associated time are events - or rather, Events - which have this attribute inherited). Web MIDI code, for example, will regularly refer to ".timeStamp" for MIDI events.

[dogben]

It's spelled "timestamp" throughout the WebRTC spec, e.g. RTCRtpContributingSource, RTCStats, and throughout Identifiers for WebRTC's Statistics API.

It's also "timestamp" in the Generic Sensor API spec, the Notifications API and a few other specs in earlier stages.

I would argue that Event.timeStamp and the type names DOMTimeStamp and DOMHighResTimeStamp are the outliers here.

[chcunningham]

we find the points about timestamp (no 'S') in other media apis compelling. editors resolved to keep it 'timestamp'