This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
As per this[1] thread on es-discuss, it is generally not appropriate to return Date objects from getters or from functions. In situations when a time-stamp is desired, it's better to simply return a integer represting "the number of milliseconds elapsed since 1 January 1970 00:00:00 UTC". In situations when a time-stamp + timezone is needed, a Date objects is not appropriate since it can't represent arbitrary timezones. We should however count on that there is existing (and new) code that uses Date objects. So we should make setters and functions accept Date objects as argument. But in all those cases should we also accept numeric timestamps. But since Date objects per normal ES coercion rules can be coerced into a number, all that we need to do in the IDL is to make the setter or function accept a numeric timestamp. That will automatically make Date objects also work. There might be cases where accepting or treating Date objects different from numeric objects. But in those cases prose could always be used. And at the very least we shouldn't worry about these cases until we actually have concrete examples. As far as I know no legacy APIs need to return Date objects or accept Date objects and treat them differently from numeric timestamps. The only stable API on the web that I can think of that uses Date objects is IndexedDB. However it needs to use prose anyway since in cases where it accepts Date objects it also accepts many other types of values that can't be expressed as a simple union. [1] http://esdiscuss.org/topic/frozen-date-objects
I'd say http://www.whatwg.org/specs/web-apps/current-work/multipage/common-input-element-attributes.html#dom-input-valueasdate is just as stable as IDB.
Ah, indeed. Based on the es-discuss conversation, I wonder if we should try to remove that function and instead introduce valueAsTimestamp().
(In reply to comment #2) > Ah, indeed. Based on the es-discuss conversation, I wonder if we should try > to remove that function and instead introduce valueAsTimestamp(). I think that .valueAsNumber() does what you would like .valueAsTimestamp() to do. This said, I am not convinced that not using Date in Web APIs is a good thing. It is not very developer friendly to use raw types such as timestamps.
Mounir: Please read the thread linked from comment 0. It is the explicit recommendation from TC39 to use numertic timestamps rather than Date objects. Feel free to jump in to that thread if you disagree though. But as of now I think the arguments are stronger than your arguments in comment 3. I don't think the existence of valueAsDate() is enough to keep Date in WebIDL. The function can always be defined to return 'Object' in the IDL.
I think Date's disadvantages have been dramatically overstated. See bug 22714 comment 13 and 22714 comment 14. HTML uses Date in two places, media.startDate() and input.valueAsDate (the latter is unfortunately an attribute, not a method, but returns a new value each time, which isn't idiomatic, but it's already deployed, so whatever), and I would certainly consider using it again where appropriate (e.g. on the <time> element's API).
So how are you handling `input.valueAsDate.setFullYear(1998)`?
Hixie, if you disagree with the conclusion about Dates I would suggest jumping in on the thread on es-discuss. As things stand I'm inclined to go with TC39s consensus.
(In reply to comment #5) > I think Date's disadvantages have been dramatically overstated. See bug > 22714 comment 13 and 22714 comment 14. HTML uses Date in two places, > media.startDate() startDate is an attribute of media elements, not a method—correct? Here is my response to Anne, re: media.startDate https://mail.mozilla.org/pipermail/es-discuss/2013-July/032030.html > and input.valueAsDate (the latter is unfortunately an > attribute, not a method, but returns a new value each time, which isn't > idiomatic, but it's already deployed, so whatever), and I would certainly > consider using it again where appropriate (e.g. on the <time> element's API). Later in that thread, I identified this list: (copied verbatim) ------------------------------- Time and/or timestamps represented as milliseconds since epoch, in the form of a number, is useful for: 1. calculating time differences with math (without coercing the object into a milliseconds number) 2. creating new Date objects if such a thing is necessary for the program 3. being the value of a property on a frozen object 4. being the value of a property who's descriptor is {[[Writable]]: false, [[Enumerable]]: false, [[Configurable]]: false} ------------------------------- My list and your list https://www.w3.org/Bugs/Public/show_bug.cgi?id=22714#c13 share a lot of overlap, however my #3 and #4 trump the pros for Date object.
File.lastModifiedDate returns a (new) Date object too.
(In reply to comment #6) > So how are you handling `input.valueAsDate.setFullYear(1998)`? It doesn't do anything useful (the returned Date is changed then GC'ed). (In reply to comment #7) > Hixie, if you disagree with the conclusion about Dates I would suggest > jumping in on the thread on es-discuss. As things stand I'm inclined to go > with TC39s consensus. It's not clear to me why that's the right forum for talking about an HTML spec feature. (In reply to comment #8) > startDate is an attribute of media elements, not a method—correct? It changed to a method recently. > ------------------------------- > Time and/or timestamps represented as milliseconds since epoch, in the form > of a number, is useful for: > 1. calculating time differences with math (without coercing the object into > a milliseconds number) > 2. creating new Date objects if such a thing is necessary for the program > 3. being the value of a property on a frozen object > 4. being the value of a property who's descriptor is {[[Writable]]: false, > [[Enumerable]]: false, [[Configurable]]: false} > ------------------------------- > > > My list and your list > https://www.w3.org/Bugs/Public/show_bug.cgi?id=22714#c13 share a lot of > overlap (Not coincidentally, I read your e-mail while writing that comment.) > however my #3 and #4 trump the pros for Date object. I don't understand how your #3 and #4 are relevant. They seem like theoretical purity, which is the least important consideration in what we often call the "priority of constituencies" (users > authors > spec writers > theory).
> > Hixie, if you disagree with the conclusion about Dates I would suggest > > jumping in on the thread on es-discuss. As things stand I'm inclined to go > > with TC39s consensus. > > It's not clear to me why that's the right forum for talking about an HTML > spec feature. It's the right forum for talking about if the Date object should be used in API design at all, no? The Date object does after all come from TC39 and they have much more experience with it than we do from HTML work, no?
(In reply to Jonas Sicking from comment #11) > > It's the right forum for talking about if the Date object should be used in > API design at all, no? The Date object does after all come from TC39 and > they have much more experience with it than we do from HTML work, no? I dunno, I think we have quite a lot of API design experience too. :-)
What is the status of this bug? It hasn't been updated in two years, and Date is still in the spec, including the Level 1 WD. Is there still an intent to remove Date? We removed use of Date from EME (issue 22824) based on this bug, but now we find ourselves looking for a common definition of time (https://github.com/w3c/encrypted-media/issues/59). Date currently provides most of that, but this bug indicates it will be removed. If this bug is still valid, I'll file a separate request for a common definition of time as a number.
The status is that this was blocked on the state of the HTML spec, but isn't anymore now that https://github.com/whatwg/html/pull/279 has been merged (earlier today). I'll do a PR to remove Date from IDL in sometime in the next few days.
https://github.com/heycam/webidl/commit/d1902ff92c28b48e81263e0d9b87e47dc587baf7