W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2013

File API | lastModified and Date attribute change

From: Arun Ranganathan <arun@mozilla.com>
Date: Mon, 2 Dec 2013 17:26:07 -0500
Message-Id: <ED882CA3-248C-4CEF-AA7E-2D04F761AEE5@mozilla.com>
To: Web Applications Working Group WG <public-webapps@w3.org>
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*
Received on Monday, 2 December 2013 22:26:40 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:20 UTC