- From: <bugzilla@jessica.w3.org>
- Date: Mon, 18 Nov 2013 15:14:17 +0000
- To: public-webapps@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23853 Bug ID: 23853 Summary: Please clarify the interpretation of the WebIDL undefined Date in the File constructor Product: WebAppsWG Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P2 Component: File API Assignee: arun@mozilla.com Reporter: costan@gmail.com QA Contact: public-webapps-bugzilla@w3.org CC: public-webapps@w3.org Step 3.3 in Section 7.1 of the File API says: "If the lastModifiedDate member is provided, let d be set to the lastModifiedDate dictionary member. If it is not provided, set d to the current date and time (which is the equivalent of Date.now() [ECMA-262])." The "lastModifiedDate" sub-section of Section 7.2 says: "If the last modification date and time are not known, the attribute must return the current date and time as a Date object." WebIDL has the concept of "undefined Date", which I think translates to "new Date(NaN)" in ECMAscript. According to 7.1 above, passing an undefined Date into the lastModifiedDate attribute of the File constructor's FilePropertyBag would require the File object to set it as its lastModifiedDate attribute, so it would be returned as it is passed. I think that "lastModifiedDate" already has a concept of unknown modification date, defined in Section 7.2, and having undefined Dates would add confusion to both users and browser developers. Can you please explicitly remove support for undefined Dates? The most reasonable solution that I could think of would be to change the first sentence of Step 3.3 in Section 7.1 to "If the lastModifiedDate member is provided, and is not the undefined Date, let d be set to the lastModifiedDate dictionary member. Otherwise, set d to the current date and time (which is the equivalent of Date.now() [ECMA-262])." -- You are receiving this mail because: You are on the CC list for the bug.
Received on Monday, 18 November 2013 15:14:19 UTC