[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

--- Comment #15 from Arun <arun@mozilla.com> ---
(In reply to Glenn Maynard from comment #13)
> (In reply to Arun from comment #9)
> 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've become pretty convinced that it *is* bad, and is a byproduct of thinking
that shiny-toy Date objects were better (more intuitive) than integers.  A
property is simpler to use than a function.  I don't think introducing a
function is worth it for this.

> 
> 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.


It is true that seconds are more intuitive than milliseconds, but we definitely
don't need sub-millisecond precision for file mods (what's a use case for
that?).

Date.now()'s been around for a long time, gives us sub-second precision for
file mods with an integer property (good enough), and has the benefit of the
affiliated Date API that readily converts to more legible formats from
milliseconds-since-UnixEpoch. 

I think long long for milliseconds-since-UnixEpoch is workable.

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

Received on Tuesday, 19 November 2013 04:04:50 UTC