22714 2013-07-17 22:33:09 +0000 Misuse of Date object 2013-07-31 21:29:10 +0000 1 1 1 Unclassified WHATWG HTML unspecified PC All RESOLVED FIXED P2 normal Unsorted 1 annevk ian cam ian mike mounir philipj contributor oldest_to_newest 90901 0 annevk 2013-07-17 22:33:09 +0000 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. 90905 1 cam 2013-07-17 23:43:53 +0000 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. 90906 2 annevk 2013-07-18 00:15:50 +0000 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. 90936 3 ian 2013-07-18 17:58:33 +0000 startDate is a time on UT1. That's what Date represents. What's the problem here? I'm confused. 91206 4 annevk 2013-07-24 06:14:54 +0000 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). 91228 5 ian 2013-07-24 16:12:46 +0000 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. 91229 6 contributor 2013-07-24 17:03:26 +0000 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 91299 7 ian 2013-07-26 00:15:20 +0000 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? 91302 8 annevk 2013-07-26 02:03:19 +0000 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. 91332 9 ian 2013-07-26 22:21:54 +0000 (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. 91333 10 contributor 2013-07-26 22:22:03 +0000 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 91338 11 annevk 2013-07-26 23:57:06 +0000 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. 91372 12 philipj 2013-07-29 06:52:50 +0000 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. 91386 13 ian 2013-07-29 19:51:41 +0000 (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. 91467 14 ian 2013-07-31 17:40:37 +0000 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. 91479 15 ian 2013-07-31 21:28:57 +0000 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. 91480 16 contributor 2013-07-31 21:29:10 +0000 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