Why lastModifiedDate being a Date object is bad? 2013/12/2 Arun Ranganathan <[email protected]>: > Greetings public-webapps, > > I'm interested in feedback from imlementors about the lastModifiedDate > attribute exposed on File objects. The latest draft of the File API spec. > describes an attribute "lastModified" which is no longer a Date object, but > rather an integer representing milliseconds since the epoch (Unix Epoch). > > TC-39 (which oversees ECMAScript) raised a number of issues with a Date > attribute used as a property. A lengthy exposé can be found in this email > thread: http://esdiscuss.org/topic/frozen-date-objects > > And note that "Date" within WebIDL itself is on shaky ground: > https://www.w3.org/Bugs/Public/show_bug.cgi?id=22824 > > Among the problems with a Date property is that it is possible to have > file.lastModifiedDate == file.lastModifiedDate test false (which is what > happens in Gecko) and allowing modifications. > > Mozilla is willing to remove lastModifiedDate completely, and migrate > developers to file.lastModified, which is an attribute that returns an > integer (long long) representing milliseconds since the epoch. The Date API > provides syntactic sugar for working with these integers, so I don't think > the developer ergonomics resulting from the move from a Date object to an > integer are too bad. > > If any other implementors have feedback about this change, we would like to > hear it. My proposal is to have developer facing documentation deprecate > .lastModifiedDate and migrate web developers over to .lastModified. The > spec. will have .lastModified only. Keeping both isn't desirable. > > -- A* > > > >
-- "Si quieres viajar alrededor del mundo y ser invitado a hablar en un monton de sitios diferentes, simplemente escribe un sistema operativo Unix." – Linus Tordvals, creador del sistema operativo Linux
