[Bug 23853] Please clarify the interpretation of the WebIDL undefined Date in the File constructor

https://www.w3.org/Bugs/Public/show_bug.cgi?id=23853

Glenn Maynard <glenn@zewt.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |glenn@zewt.org

--- Comment #13 from Glenn Maynard <glenn@zewt.org> ---
(In reply to Arun from comment #9)
> Note that the spec. originally had a long long, but arguments made on the
> listserv for developer "ease of use" favored Date (it was, after all, a last
> modified date, so why not use the Date abstraction?).  But it seems like
> this imposed the limitation of file.lastModifiedDate ==
> file.lastModifiedDate returning false, which is bad.

It's okay that file.lastModifiedDate != file.lastModifiedDate.  The only
problem is that it should be a function instead of a property, I think, since
it doesn't behave like a property.  I don't know if changing that at this point
is worth it or not.

I think it's very bad if file.lastModifiedDate.valueOf() !=
file.lastModifiedDate.valueOf(), though, which seems to be implied (depending
on timing) by "the attribute must return the current date and time".  If no
mtime is available, lastModifiedDate should be the the File was instantiated,
not the time of the call, so the File appears immutable.  Also, new File(file)
should copy that time.

I'm unconvinced about returning a number.  It doesn't seem bad if it's done
across the platform with all new APIs, but it's bad if this one API does it and
nobody else does.  It might be a good idea to ping a wider audience for
thoughts on this first.

If numbers are used, I'd recommend using seconds as a double, not milliseconds
as an integer.  Date.now() is a bad precedent: millisecond ints are annoying
and can't deal with sub-millisecond precision.  Better to break from that and
use floating-point seconds since the epoch, like the rest of the world.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Tuesday, 19 November 2013 02:17:04 UTC