- From: <bugzilla@jessica.w3.org>
- Date: Tue, 19 Nov 2013 04:04:49 +0000
- To: public-webapps-bugzilla@w3.org
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