This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Per https://mail.mozilla.org/pipermail/es-discuss/2013-July/032038.html HTMLMediaElement.startDate should really have used DOMTimeStamp instead. Can we still change that? Also, it might be that most of HTMLInputElement.valueAsDate doesn't strictly require Date objects either. I have not investigated that in detail however. The property of obj.attribute != obj.attribute seems horribly wrong though, so maybe HTMLInputElement.valueAsDate should be changed anyway.
If HTMLInputElement exposed the time/date value as milliseconds since the epoch, then it's a bit awkward for the author to have to construct a Date object from it so that they can easily extract, year, month, day, etc. I must admit this is the first I have heard that Date objects are not good for representing times/dates without timezone information.
Note that further on in the thread it is pointed out that currently Date objects are simply a wrapper for a timestamp and do not contain timezone information.
startDate is a time on UT1. That's what Date represents. What's the problem here? I'm confused.
The problem is obj.startTime != obj.startTime. In addition, the JS community doesn't want us to use Date but just use DOMTimeStamp (i.e. a number).
Well we can easily solve obj.startTime != obj.startTime, just cache the Date object between changes to the timeline offset. I don't understand why Date would be the wrong thing to return here. It seems eminently ideal for this.
Checked in as WHATWG revision r8083. Check-in comment: Make media.startDate return the same object until the time changes. (also, typo in dependencies section) http://html5.org/tools/web-apps-tracker?from=8082&to=8083
So the only argument now seems to be "the JS community doesn't want us to use Date but just use [...] a number". Can you elaborate on that argument?
What you are currently doing violates IDL. The semantics from a developer perspective are weird, because a Date is not immutable, but mutating the object's state will not affect anything. I think the JS perspective is to not expose a more complicated thing when something much simpler is sufficient. If you disagree with this I'd encourage you to engage on es-discuss.
(In reply to comment #8) > What you are currently doing violates IDL. How so? > The semantics from a developer perspective are weird, because a Date is not > immutable, but mutating the object's state will not affect anything. Well that's why it was returning a unique value before, but you didn't like that either. I've gone back to the old behaviour. > I think the JS perspective is to not expose a more complicated thing when > something much simpler is sufficient. If you disagree with this I'd > encourage you to engage on es-discuss. I'm happy to leave the spec as is. I don't understand the problem here. We could always return "something simpler" — should we return the whole DOM as just a string, rather than elements? That makes no sense to me. I think the fact that (new Date(0)) != (new Date(0)) is really just as much of a problem as the fact that video.startDate != video.startDate. Returning a number is dumb, since it's not a number — it's very specifically a date. A Date object is just a number representing a date wrapped in a useful API for managing this kind of thing. It seems like exactly what is needed here. If someone has a concrete problem with this, they should file a bug (or reopen this one) rather than going through a proxy without explaining to the proxy what the actual problem is.
Checked in as WHATWG revision r8094. Check-in comment: Revert r8083, since it leads to weird behaviour worse than just returning a new object each time. (It seems this isn't implemented by anyone yet anyway.) http://html5.org/tools/web-apps-tracker?from=8093&to=8094
I think the specific complaint is that the Date object is not a useful API and that a number is typically easier to work with. Again though, I'm relaying what the developer community and the committee in charge of JavaScript feel is the best thing. If this isn't implemented we should definitely switch to DOMTimeStamp or maybe something that allows millisecond precision like the other parts of the media API.
It might be useful to have a look at what the underlying data exposed through .startDate is. For WebM <http://www.webmproject.org/docs/container/>, I believe it would be DateUTC, which makes a lot of sense to represent as a Date, IMHO. As an aside, Matroska <http://matroska.org/technical/specs/index.html> dates is a "signed 8 octets integer in nanoseconds with 0 indicating the precise beginning of the millennium" so conversion is needed in any case.
(In reply to comment #11) > I think the specific complaint is that the Date object is not a useful API How is it a less useful API for exposing a Date and Time than Number? I really don't understand. Could you give a concrete example of how it's less useful? (Note that Date can be converted to Number trivially. It has a valueOf.) > I'm relaying what the developer community and the committee in charge of > JavaScript feel is the best thing. Can you provide URLs of where the developer community is indicating concern over startDate being exposed as a date? I would love to see what developers are trying to do with it that they would find more easy if it was a Number object than a Date object. > If this isn't implemented we should definitely switch to DOMTimeStamp or maybe > something that allows millisecond precision Date allows millisecond precision already. I'm not a priori objecting to changing the API. But I *am* objecting to changing the API based on no reasoning whatsoever. Currently the benefits of each approach are as follows: - Returning a Number + you can find the difference between them by subtraction. + you can compare them using < and >. + you can compare the two video's startDates for equality using x==y instead of having to use (x<=y)&&(x>=y). - Returning a Date + has a useful API for manipulating Dates, e.g. you can find out what the time is in the user's time zone and render it as such trivially, as well as comparing individual parts of it like the time or month. + you can find the difference between them by subtraction. + you can compare them using < and >. In practice, the use cases for startDate are three-fold, as far as I can tell: 1. Displaying a string to the user (typically just the time), on the seek bar. 2. Subtracting the time from another time to find an offset for adjusting out- of-band timings (e.g. displaying a synchronised slide show) 3. Checking which of two streaming videos started earlier. These three use cases map exactly to the "pros" of Date, and more of them are handled by Date than by number. The ability to compare dates _for equality_ more easily using numbers than Dates doesn't affect any of the use cases. If you really do want to compare two Date objects x and y for equality, there's a multitude of ways to do so: (x <= y) && (y >= x) x.valueOf() == y.valueOf() x-y == 0 x-0 == y-0 It's no different than if you had Number objects instead of literal numbers.
Other benefits of using Date that I hadn't thought of, based on the feedback here: https://twitter.com/annevk/status/362017983461212160 + it has a better representation when serialising to JSON (it converts to a string that looks like a date, not an opaque number). + it has an API to convert to ISO8601 format.
Since the only disadvantage of using a Date is that it's confusing that Date attributes return objects that aren't live (mutating the object doesn't affect the underlying object, and the "readonly"ness doesn't propagate to the Date itself), I've changed the spec to use a method instead.
Checked in as WHATWG revision r8113. Check-in comment: Change startDate to a method to avoid the confusion of it being mutable. http://html5.org/tools/web-apps-tracker?from=8112&to=8113