The recommendation from TC39 is to stop using Date objects entirely, and instead simply use numeric values.

Which browsers implement File.lastModifiedDate? If it's few enough we can probably simply change the type to be a number.

Gecko implements it, with the spec's current semantics (which means in Gecko file.lastModifiedDate == file.lastModifiedDate tests false, funtimes).

But I would be quite happy dropping this from Gecko if we possibly can.  Because again, the semantics are not good.

So "lastModifiedDate" would return a... number?

lastModifiedDate is at least supported by Chrome, Firefox and Safari.

If the general desire is to follow the TC39 recommendations, I would suggest removing/deprecating the lastModifiedDate attribute and introducing a lastModified that returns a number. This way, browsers can sunset the attribute based on usage data.

On the other hand, the File constructor, together with the FilePropertyBag, are just getting implemented in Firefox and Chrome, and are considered experimental.

Boris: according to my interpretation of the current File spec, if a File is constructed using the file constructor, e.g.

var file = new File([], "");

then file.lastModifiedDate should always return the same value. Step 3.3 in Section 7.1 says that the lastModifiedDate should be set to the current time, so lastModifiedDate should always return the time when the File was constructed.

Am I wrong?

> So "lastModifiedDate" would return a... number?

Yes.  Number of milliseconds since the epoch. 

I don't have strong feelings about naming it.

> Am I wrong?

You are.  The relevant spec here is http://heycam.github.io/webidl/#es-Date and in particular this bit:

  Otherwise, return a newly constructed ECMAScript Date object that represents
  the same millisecond as V.

so if you have IDL saying your return value is a Date, you get a new Date object every time.

Has to be done this way, because if the same object were returned every time the page could directly mutate the lastModifiedDate of the file by doing things like:

  file.lastModifiedDate.setFullYear(1999);

or whatnot, no?

Thank you very much for explaining, Boris!

I'm sorry, I was thinking of the values behind the Date instances. You are completely correct.

Regarding the property name, I just think we'd have a smoother transition if we have a new property with a different name. I have no data suggesting that we need to worry about this though, so feel free to ignore me.

I just learned that lastModified might be a bad name choice, because the DOM specification defines a lastModified attribute on Document that is a DOMString.
http://www.w3.org/html/wg/drafts/html/master/dom.html#dom-document-lastmodified

Renaming to lastModified and making it return a number sounds like a good solution.

Jonas, would this apply to the lastModifiedDate attribute of the FilePropertyBag in the File constructor as well?

Also, if the spec is moving that way, can we please have a type of "long long" or at most "double" for lastModified? Please don't make it an unrestricted double.

(In reply to Victor Costan from comment #8)
> Jonas, would this apply to the lastModifiedDate attribute of the
> FilePropertyBag in the File constructor as well?
> 
> Also, if the spec is moving that way, can we please have a type of "long
> long" or at most "double" for lastModified? Please don't make it an
> unrestricted double.


We don't have to make the FilePropertyBag member be the same, but I think it simplifies things if we do that.  

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.

We'll switch to a 'long long' in both places -- as a FilePropertyBag bag member (with default equivalent to Date.now()) and the attribute on File.

Thank you very much, Arun!

Just to make sure I understand:

1) File gets a "lastModified" attribute that is a long long, and the "lastModifiedDate" File attribute will be removed from the spec.

2) The FilePropertyBag used in the File constructor also gets a "lastModified" attribute of type long long, instead of "lastModifiedDate".

Is this correct?

(In reply to Arun from comment #9)
> (In reply to Victor Costan from comment #8)
> > Jonas, would this apply to the lastModifiedDate attribute of the
> > FilePropertyBag in the File constructor as well?
> > 
> > Also, if the spec is moving that way, can we please have a type of "long
> > long" or at most "double" for lastModified? Please don't make it an
> > unrestricted double.
> 
> 
> We don't have to make the FilePropertyBag member be the same, but I think it
> simplifies things if we do that.  
> 
> 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.
> 
> We'll switch to a 'long long' in both places -- as a FilePropertyBag bag
> member (with default equivalent to Date.now()) and the attribute on File.

Material information this long thread on the matter: http://esdiscuss.org/topic/frozen-date-objects

... which culminated in Jonas logging Bug 22824

I still think switching to long long is regrettable but necessary.

(In reply to Victor Costan from comment #10)
> Thank you very much, Arun!
> 
> Just to make sure I understand:
> 
> 1) File gets a "lastModified" attribute that is a long long, and the
> "lastModifiedDate" File attribute will be removed from the spec.
> 
> 2) The FilePropertyBag used in the File constructor also gets a
> "lastModified" attribute of type long long, instead of "lastModifiedDate".
> 
> Is this correct?

Yep.  Though in 2.) we might say that the default is the long long that is the equivalent of Date.now().

Indeed. TC39 basically said that the Date object is so riddled with problems that it's generally better to avoid it in specs.

And yes, I would say that we should use a numeric 'lastModified' in the dictionary too.

Note that this still means that you can pass a Date object as value for lastModified. This since converting a Date object to a numeric value is defined by ES as grabbing the internal value inside the Date. So it will 'just work' without having to do anything special in neither the WebIDL or in the implementation.

But yes. I think File.lastModified should return a number.

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

> It doesn't seem bad if it's done across the platform with all new APIs

That's the plan.

> If numbers are used, I'd recommend using seconds as a double, not milliseconds
> as an integer.

_That_ makes it pretty unclear how to get a Date out of it.

If we want sub-millisecond precision (not sure how useful this is for File), we could do a millisecond-since-epoch double.

> like the rest of the world

Where on the web are seconds-since-epoch used?

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

As a Web developer, I would definitely prefer milliseconds-since-epoch, so I can add/subtract dates. It is a bit awkward to work with this format, but I already have to do this for Date values and setTimeout / setInterval.

Having two units of measurement introduces an extra inconsistency that would make it difficult to understand or review any code involving dates.

As far as "double" vs "long long" goes, I will implement what you decide on.

Lets not fix dates on the web here. Existing convention is to use milliseconds since epoch everywhere else. Using an integer seems both forwards compatible and exact enough for now.

Marking this fixed: http://dev.w3.org/2006/webapi/FileAPI/#file-constructor

(It's also fixed in the WebIDL: http://dev.w3.org/2006/webapi/FileAPI/#file and in the attribute definitions: http://dev.w3.org/2006/webapi/FileAPI/#file-attrs).

This is probably the last open bug before RC, so anyone with time to give the draft a once-over is encouraged to do so.

(I think this change was made at best prematurely and probably in error, and the idea of avoiding the use of JavaScript objects in random APIs because you don't like a particular wart of equality common to *every* JavaScript object--URL, Map, common objects used as dictionaries--makes no sense at all.  But, making a spec change and closing the bug without bothering to wait for me to reply, not even a day, completely erased my interest in trying to help.)

Glenn, I would be very interested in why you think Date should be used in the _constructor_.  Or do we agree that using a numeric timestamp there is maximally compatible (and still allows callers to pass in a Date)?

As for returning a value, you're right that there is a problem common to a number of JS objects that have internal state but you don't want the page to mutate.  Note that this is not a problem for dictionaries (e.g. you could return a frozen one), but _is_ a problem for Map and Date, because those can't be meaningfully made immutable.  One could, of course, return proxies that disallow the mutation methods... There are a bunch of open issues here, and I'd welcome your input on solving them, on public-script-coord.

(In reply to Boris Zbarsky from comment #20)
> Glenn, I would be very interested in why you think Date should be used in
> the _constructor_.  Or do we agree that using a numeric timestamp there is
> maximally compatible (and still allows callers to pass in a Date)?

We're talking about changing it for both--you wouldn't change it for the ctor but not for the property.  I don't think using a number is bad, but I think the reasons for changing it now, on a feature that appears to already be implemented in Chrome, Firefox and IE, are at least poorly established.  (You could add a scalar version of the property without removing the Date version, but that seems even less worthwhile.)

> As for returning a value, you're right that there is a problem common to a
> number of JS objects that have internal state but you don't want the page to
> mutate.

I meant the issue that while x > y and x < y work, x == y has a different meaning and you need a separate method to test equality.  It's lame, but it's a language-level lameness that affects every class on the platform, and it shouldn't be an argument against using objects.

I think the mutability issue is less serious: returning a new object isn't a big deal.  It would be better to have a function instead of a property in that case, but I don't think it'd be worth changing it at this point.

> Note that this is not a problem for dictionaries (e.g. you could
> return a frozen one), but _is_ a problem for Map and Date, because those
> can't be meaningfully made immutable.  One could, of course, return proxies
> that disallow the mutation methods... There are a bunch of open issues here,
> and I'd welcome your input on solving them, on public-script-coord.

I'd expect an immutable Date to be a base class of Date that simply doesn't have the mutation methods in the first place.  I thought about that a bit, but I'm not sure it's worth it compared to just returning a new object each time.

> you wouldn't change it for the ctor but not for the property

Why wouldn't you?  It makes a lot of sense to take millisecond timestamps in all places where you _accept_ dates.  Returning dates is more complicated in terms of object vs timestamp.

> I meant the issue that while x > y and x < y work, x == y has a different
> meaning and you need a separate method to test equality.

Yes, I understand that.  But that's only an issue because a new Date object is returned every time.  The sane thing to do would perhaps be to return a Date object that the caller cannot modify, but there is no such thing in ES right now.

> It's lame, but it's a language-level lameness that affects every class on the
> platform, and it shouldn't be an argument against using objects.

It's an argument against _minting_ objects. It's not just == that's broken.  You get things like:

  foo.bar.x = "something";
  alert(foo.bar.x); // hey, undefined

and people rightly start cursing the API designer.

(In reply to Boris Zbarsky from comment #22)
> > you wouldn't change it for the ctor but not for the property
> 
> Why wouldn't you?  It makes a lot of sense to take millisecond timestamps in
> all places where you _accept_ dates.  Returning dates is more complicated in
> terms of object vs timestamp.

(I'm confused.  I read "why you *don't* think it should be used in the constructor".  You actually asked "why you think it should be", but I didn't say that.  I don't care if the ctor accepts *additional* types; what I'm unconvinced by is the breaking change to the widely-implemented File.lastModifiedDate.)

> > I meant the issue that while x > y and x < y work, x == y has a different
> > meaning and you need a separate method to test equality.
> 
> Yes, I understand that.  But that's only an issue because a new Date object
> is returned every time.  The sane thing to do would perhaps be to return a
> Date object that the caller cannot modify, but there is no such thing in ES
> right now.

No, the same thing happens if the user opens the same file in two places, or if you clone the File object, or if you have two files with the same timestamp.

> > It's lame, but it's a language-level lameness that affects every class on the
> > platform, and it shouldn't be an argument against using objects.
> 
> It's an argument against _minting_ objects. It's not just == that's broken. 
> You get things like:
> 
>   foo.bar.x = "something";
>   alert(foo.bar.x); // hey, undefined
> 
> and people rightly start cursing the API designer.

Only because foo.bar is a property.  I think it's natural that a function foo.getBar() gives a new object every time.

Yes, if this were not a property it would be a lot saner, I agree.

Glenn: I've decided to re-open this bug (per Comment 19 and further) and I apologize if you feel that it was rushed through without discussion.  It didn't seem that big a leap (based on the es-discuss thread) to phase out a Date-based property, but on that account I could be wrong.

I am very interested in information from implementers about lastModifiedDate, and whether they are comfortable about deprecating it in favor of the proposed "lastModified" which will have an integer type, not a Date object type.  If it cannot be removed or safely deprecated, then it should stay in the spec.  And by "stay in the spec" I think there will be now be two properties, since I don't think Date serves us as a readonly property, and having an integer alternative *that can rely on the Date API* for syntactic convenience isn't a bad trade-off.

but that would also not be backwards compatible.

what we had with lastModifiedDate was simply a bad API. Better remove it now while we still have a chance to than keep it in the platform and cause developers subtle bugs.

In addition to the reasons mentioned so far, it was bad because Date objects are generally advicwd against by TC39. If you disagree with that I suggest you bring it up with them. But read the thread about "frozen dates" on the es-discuss list first.

There have been no arguments made for why Date is a bad API (only that File should have put it on a function rather than a property), and "because someone else says so" isn't close to good enough for changing an API that's already deployed in every major browser.

The most likely result is that we end up with *both* properties on File, and that's the worst possible outcome.  (Whatever things you don't like about the current API would remain, so adding a second property doesn't help at all.)

(In reply to Glenn Maynard from comment #27)
> There have been no arguments made for why Date is a bad API (only that File
> should have put it on a function rather than a property), and "because
> someone else says so" isn't close to good enough for changing an API that's
> already deployed in every major browser.


Date is a bad choice for a readonly attribute, and using it in the File API for a readonly attribute is a bug.  

1. It makes the readonly nature of an attribute suspect -- this makes it a bad API choice for a readonly attribute.  We shouldn't change it to a function now since I think that's too much API for too little value.
2. It returns new values each time, which leads to false tests of equality, which is illogical.  This makes it a bad API choice for a readonly attribute.
3. It's likely to be removed from WebIDL, so it's not a future-safe choice.

In retrospect I (we) should have pushed harder on the choice to make the attribute return a Date, but... hindsight is etc. etc.

I think the real debate is whether it's too late a breaking change for implementers to rally behind.  That's the only point worth arguing, honestly.


> The most likely result is that we end up with *both* properties on File, and
> that's the worst possible outcome.  (Whatever things you don't like about
> the current API would remain, so adding a second property doesn't help at
> all.)

Agreed.  I'd MUCH rather remove lastModifiedDate and expunge it from the spec. altogether.  Since the only valid point worth debating is whether that's too late a change, out of caution I reopened this bug and polled the listserv.  Implementers are encouraged to respond soon.

(In reply to Arun from comment #28)
> 1. It makes the readonly nature of an attribute suspect -- this makes it a
> bad API choice for a readonly attribute.  We shouldn't change it to a
> function now since I think that's too much API for too little value.

Changing it from an object to a number is a much bigger change than changing it from a property to a function.  If it's not enough of a problem to change it to a function, it's definitely not enough of a problem to change the very data type.

(I don't think it should be changed to a function at this point, because I indeed don't think it's enough of a problem in an API already implemented everywhere.)

> 2. It returns new values each time, which leads to false tests of equality,
> which is illogical.  This makes it a bad API choice for a readonly attribute.

*All* value-like JavaScript objects have unfortunate behavior for the == operator.  It's the same with dictionaries, Map, URL, and every other object where people want to compare them as values.  This isn't a reason to not use objects; it's just a JavaScript wart that we have to live with.

> 3. It's likely to be removed from WebIDL, so it's not a future-safe choice.

Date is not going away, no matter what WebIDL does.

> Agreed.  I'd MUCH rather remove lastModifiedDate and expunge it from the
> spec. altogether.  Since the only valid point worth debating is whether
> that's too late a change, out of caution I reopened this bug and polled the
> listserv.  Implementers are encouraged to respond soon.

Telling people that the points they're discussing are "not valid and not worth debating" is dismissive and offensive.

(In reply to Glenn Maynard from comment #29)
> (In reply to Arun from comment #28)
> > 1. It makes the readonly nature of an attribute suspect -- this makes it a
> > bad API choice for a readonly attribute.  We shouldn't change it to a
> > function now since I think that's too much API for too little value.
> 
> Changing it from an object to a number is a much bigger change than changing
> it from a property to a function.  If it's not enough of a problem to change
> it to a function, it's definitely not enough of a problem to change the very
> data type.
> 
> (I don't think it should be changed to a function at this point, because I
> indeed don't think it's enough of a problem in an API already implemented
> everywhere.)


I think we agree that it shouldn't be changed to a function.  I think allowing a Date in the constructor, even if as an incidental benefit, is a good thing.  Also, the integer can be read with a Date, so it isn't a huge leap IMHO, though perhaps more lines of code.  Instructive code snippets might help the spec here, both for the constructor and for reading a date that's an integer.

It would be nice if separately we could find a freezable date abstraction, but that takes us out of the scope of the File API.


> 
> > 2. It returns new values each time, which leads to false tests of equality,
> > which is illogical.  This makes it a bad API choice for a readonly attribute.
> 
> *All* value-like JavaScript objects have unfortunate behavior for the ==
> operator.  It's the same with dictionaries, Map, URL, and every other object
> where people want to compare them as values.  This isn't a reason to not use
> objects; it's just a JavaScript wart that we have to live with.


Of course this is an issue with JS objects in general, but I think this is a good reason to use caution when specifying a readonly property that is supposed to ultimately yield a measurable value.  And of course, we can't avoid the use of value-like JS objects altogether, but we should make reasonable guarantees of logical behavior when specifying attributes.

Right now, the particularly problematic behavior is for *Date.*  We have this problem in general, but it's with Date that we see this most acutely, when in fact the value for unmodified files should behave like comparable integers that test true.


> 
> > 3. It's likely to be removed from WebIDL, so it's not a future-safe choice.
> 
> Date is not going away, no matter what WebIDL does.


This is true, but we can avoid the introduction of instabilities by trying to do the right thing.  Enough people seem to agree with this general technical direction (including some implementers, judging from the es-discuss thread), though the point of whether this is too late breaking a change is still valid.


> 
> > Agreed.  I'd MUCH rather remove lastModifiedDate and expunge it from the
> > spec. altogether.  Since the only valid point worth debating is whether
> > that's too late a change, out of caution I reopened this bug and polled the
> > listserv.  Implementers are encouraged to respond soon.
> 
> Telling people that the points they're discussing are "not valid and not
> worth debating" is dismissive and offensive.


I think we can reasonably disagree, and (once again) apologize if my tone isn't reasonable.  In Comment 13 you were just about on board with using numbers ("...if numbers are used..."), which is what prompted me to close this bug in the first place (sure, you may have been an advocate for seconds-since-epoch and the use of double, but that's already agreement with the change).

I agreed with your point about this being a late-breaking change, which is why I reopened this.  I will close it modulo feedback on the listserv from implementers (or feedback here).

Glenn, if you want to continue using Date objects here Insugest you jump into the threat at [1] and convince them that it is the right thing to do.

[1] http://esdiscuss.org/topic/frozen-date-objects

I've added sample code for File construction and metadata extraction, largely to prove to myself that the change isn't too painful.  It isn't IMHO.

I implemented a use counter in Blink (Chrome) to track the usage of lastModifiedDate. I will report back when we have some data.

FWIW, we currently support both lastModifiedDate and lastModified. The latter is behind the same flag (Enable experimental Web Platform features) as the File constructor in the ED.

(In reply to Victor Costan from comment #33)
> I implemented a use counter in Blink (Chrome) to track the usage of
> lastModifiedDate. I will report back when we have some data.
> 
> FWIW, we currently support both lastModifiedDate and lastModified. The
> latter is behind the same flag (Enable experimental Web Platform features)
> as the File constructor in the ED.

Thank you for this, Victor :) Relevant changes (as of yesterday) are http://dev.w3.org/2006/webapi/FileAPI/#file

I think we can safely close this bug, having left it open for further info.

I realize that the bug is closed, but I'm adding use counter information anyway, for completeness. I think that my use counters have finally been out in Chrome's stable channel long enough to be meaningful.

It appears that lastModifiedDate is used in 0.0162% of Chrome's page views. This should be low enough to deprecate and remove it in favor of lastModified.
http://www.chromestatus.com/metrics/feature/popularity#FileGetLastModifiedDate