Re: File API | lastModified and Date attribute change

Why lastModifiedDate being a Date object is bad?

2013/12/2 Arun Ranganathan <arun@mozilla.com>:
> 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

Received on Monday, 2 December 2013 23:21:47 UTC