Closed Bug 585152 Opened 10 years ago Closed 9 years ago

Make Date.now() return fractional as well as integral bits (for submillisecond timing)

Categories

(Core :: JavaScript Engine, defect)

Other Branch
x86
Windows CE
defect
Not set

Tracking

()

RESOLVED WONTFIX

People

(Reporter: paul.biggar, Unassigned)

References

Details

(Whiteboard: [aurora-backout])

Attachments

(1 file, 2 obsolete files)

Attached patch Make Date.now() return a float. (obsolete) — Splinter Review
Date.now() returns an integer within a Number, which truncates valuable accuracy. It is trivial to return a double with a Number.

Note that I've been usnig this patch locally for a few weeks, and it is the most important part of reducing the variability in SunSpider, as seen in bug 580532 (see https://bugzilla.mozilla.org/show_bug.cgi?id=580532#c24 "Better date resolution".


The ECMAscript standard seems OK with it, but as Brendan says 'that code has "always been that way" :-/'

Relevant standard bit:

15.9.4.4 Date.now ( ): The now function return a Number value that is the time value designating the UTC date and time of the occurrence of the call to now.
Summary: Make Date.now() return a float value → Make Date.now() return a double value
Summary: Make Date.now() return a double value → Make Date.now() return fractional as well as integral bits (for submillisecond timing)
You are asking for trouble. We should test this very carefully. I am sure we will break the web in exciting ways with this change.
We probably can't change Date.now.

Adding a high resolution timer and using it instead of Date.now would be better.
We should think twice what we are trying to do here. If you want to measure sunspider better, lets add special functionality in our builds for that. If we think this is useful for the web, full speed ahead but mark my words: this is going to be painful :)
We talked more on IRC, and jorendorff pointed out that ES5 15.9.4.4 Date.now () is underspecified and does not say anything about TimeClip being called. So this seems like an allowed implementation choice.

Date.now() is new in ES5 so I doubt we'll break the web anyway. Even if it is used, it'll be used for delta arithmetic and < or <= tests -- not isInteger tests (hard to write in JS).

Paul is gonna raise the underspecification issue (or feature ;-) on es-discuss.

/be
(In reply to comment #2)
> We probably can't change Date.now.

We can change it, though.

Does SS use it? I woulda thunk SS and V8 use (new Date()) - start, e.g.

> Adding a high resolution timer and using it instead of Date.now would be
> better.

That is a separate proposal, adding a nanoAge method to date objects (from the ES4 proposal at

http://wiki.ecmascript.org/doku.php?id=proposals:date_and_time&s=nanoage

and due to be revamped and added to the strawman namespace for Harmony).

/be
I think this is a fine bug as written, it seems ES5 conformant and Date.now is new in ES5. I'm just not sure it'll help ES3-targeted benchmarks.

/be
(In reply to comment #4)
> 
> Date.now() is new in ES5 so I doubt we'll break the web anyway. 

Date.now already ships in every browser on my mac. Maybe some of them return doubles.

(In reply to comment #6)
> I'm just not sure it'll help ES3-targeted benchmarks.

It helps by making them easier to measure.

We can measure the benchmarks better without working on the standard or introducing possible web compatibility problems. The concerns are separable.
Brendan didn't like changing the behaviour of NowAsMillis.
Attachment #463643 - Attachment is obsolete: true
(In reply to comment #5)
> Does SS use it? I woulda thunk SS and V8 use (new Date()) - start, e.g.

SS and v8 both use (new Date()).

Code which uses (new Date()) can optionally use Date.now by checking for its presence, which is what I'll propose to SS folks.
https://mail.mozilla.org/pipermail/es-discuss/2010-August/011648.html(In reply to comment #4)
 
> Paul is gonna raise the underspecification issue (or feature ;-) on es-discuss.

https://mail.mozilla.org/pipermail/es-discuss/2010-August/011648.html
If we just want something better for SunSpider, let's make a timestamp class/function for JavaScript. It's a real pain/expense to get a high resolution date and far less pain/time to get a high resolution timestamp on Windows. I'm not sure how it is on other platforms. The other option is to make SunSpider not require sub-ms resolution.
There's a nascent proposal in bug 539095 for a thing much like you describe.  Brendan also points out Date.prototype.nanoAge (http://wiki.ecmascript.org/doku.php?id=proposals:date_and_time&s=nanoage).  These are complementary to fractional Date.now, IMHO.
(In reply to comment #11)
> It's a real pain/expense to get a high
> resolution date and far less pain/time to get a high resolution timestamp on
> Windows.

This proposal is to simply stop throwing away the information we have. The patch just changes a denominator from 1000 to 1000.0.

> I'm not sure how it is on other platforms. The other option is to make
> SunSpider not require sub-ms resolution.

SunSpider doesn't require it, but we want to introduce it to SunSpider because the consistency of SunSpider is so bad. See https://bugzilla.mozilla.org/show_bug.cgi?id=580532#c24
The es-di(In reply to comment #10)
> > Paul is gonna raise the underspecification issue (or feature ;-) on es-discuss.
> 
> https://mail.mozilla.org/pipermail/es-discuss/2010-August/011648.html

The es-discuss list was silent, with the exception of Crockford, who said "I think this is a good idea. I like this a lot". As I understand it, if this were going to break the web, someone there would have raised it.

So, pros:

 1) Much more accurate information to people using Date.now() to time things (its only real function)
 2) Date.now() is new to ES5
 3) Date.now() will still return a Number
 4) The change is according to spec
 5) The es-discuss list has raised no problems
 6) Crockford likes it; Brendan likes it.
 7) Date.now() seems to be largely unused on the web:
   - I have trouble even finding it when I google for it
   - Our own docs list Date.now() as non-standard (https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Date)


Cons:
 1) I believe other browsers provide no fractional bits for Date.now() (I checked Firefox 3 and Chrome 5, I'll assume the same is true for others)
 2) It may break the web in a way we don't understand.

I think con 2 is mitigated by pros 2-5 and 7. Based on this, it looks like we should go for it. If needs be, I can also:

 - ask other browser vendors to do the same
 - ask in JS communities online to see if I can find some code that would break with this change.
I vote for trying to get this into FF5 or FF6.  Who's with me?
(In reply to comment #15)
> I vote for trying to get this into FF5 or FF6.  Who's with me?

Me.
Note that the original sunspider use case is gone; the remaining reason to do this is that it would be cool for the web.
Let's just do it and see what happens: we can back it out if it breaks things.

My personal take is that high-resolution timers are important for all kinds of applications, and for some weird reason are neglected by many APIs and libraries. We have a chance to fix that here.
How is this looking for FF5?
(In reply to comment #19)
> How is this looking for FF5?

Paul, is that patch ready for review?
It applies and is trivial, but I want to add some tests (in particular, what happens when we pass doubles to things which expect the results of this function).

It'll be ready at the weekend, I'm trying to finish up other stuff now.
Version: Trunk → Other Branch
OK, had some time to play with this. I can't figure out a way to test this - it doesn't even change the signature.
Attachment #463650 - Flags: review?(jwalden+bmo)
Comment on attachment 463650 [details] [diff] [review]
Make date.now include fractional bits.

>+static inline jsdouble
>+NowAsFractionalsMillis()
>+{
>+    return (jsdouble) (PRMJ_Now() / double(PRMJ_USEC_PER_MSEC));

No need for the outer cast here, so get rid of that.
Attachment #463650 - Flags: review?(jwalden+bmo) → review+
http://hg.mozilla.org/tracemonkey/rev/eee087772f45
Whiteboard: [fixed-in-tracemonkey]
Backed out, turns Moth and X orange.  The X orange is simple enough (fractional time passed to API that truncates to int, then test compares fractional to API getter => mismatch; easily solved by Math.floor), but Moth wasn't obvious at a glance.  You probably want to build a browser and test that to figure out what's up.
Whiteboard: [fixed-in-tracemonkey]
The X orange is pretty simple - there were some comparisons against the result of Date.now(), which is now not going to succeed since, and was pretty flaky to begin with.

The M(oth) orange is horrific. As far as I can tell, we store the result of Date.now() somewhere. We then retrieve it a long time later, and concatenate it with a string. We then try to access the result as a variable or DOM node or something, and get a syntax error.

Concretely:

x['saveme'] = Date.now()
...
res = x['saveme']
id = 'hud_' + res // id now has an unexpected '.' in it
do_something(y[id]) // syntax error or something

Logs of the M(oth) case at http://tinderbox.mozilla.org/showlog.cgi?log=TraceMonkey/1302551000.1302555978.4259.gz&fulltext=1#err0.
  var uniqueId = "panel" + Date.now() + position;

in tabbrowser.xml inside <method name="addTab"> seems like a plausible culprit there if I read the hudservice jsm correctly.  I have no idea _why_ hudservice can't handle the different ID structure there, but apparently it can't....
So a simple win might be to round in tabbrowser.xml for now...
Changing the form of the generated tabbrowser IDs is undesirable, many consumers other than HUD Service likely depend on it. It's gross but there isn't much we can do about it now. You should just round in tabbrowser.xml - I can r+ that patch.
Bug 586153 would also like to remove the time-driven panel IDs. I would also r+ that patch. ;)

I'm pretty surprised there's talk of doing this, though. Seems like it would break a lot of code that fairly assumes this is always an integer. But I have nothing more to add to this objection than has already been raised.

I just want to tell you both good luck. We're all counting on you.
the problem seems to be here: http://mxr.mozilla.org/mozilla-central/source/toolkit/components/console/hudservice/HUDService.jsm#1445

1444     let hudId = "hud_" + nBox.id;
1445     let displayNode = nBox.querySelector("#" + hudId);

this ends up doing a querySelector("#x.y"); that gives a NS_ERROR_DOM_SYNTAX_ERR
To be clear, that code should just escape the selectors meta characters, it fails because tries to evaluate "#someid.0", the numeric value is clearly an error, while it should work with "#someid\\.0".
Why doesn't that use nBox.getElementById(hudId)?
Oops, forgot that was one of those methods not also defined on nodes or elements.  But surely there's something better than having to parse a CSS selector here...
There really isn't.
OK, that looks like it fixes it. Maybe.

This afternoon I went through every dodgy looking Math.now() and wrapped it in a Math.floor(). So that makes a larger patch than has been auto r+ed above. Is anyone still here to r+ this one? I'll have it in 20 mins when I rebase, recompile and rerun the tests.
Anyone still awake? We've got 2 hours to see if it sticks.

This is rebased (still recompiling and testing post rebase), but I plan to push nearly as soon as I get r+.
Attachment #463650 - Attachment is obsolete: true
Attachment #525301 - Flags: review?(dolske)
Attachment #525301 - Flags: review?(gavin.sharp)
rs=me for a push to TM for what it's worth -- these changes are all pretty obvious reversions to current behavior.  If it passes the test gauntlet on TM I'm willing to extend it to m-c as well, but without precise knowledge of all that code I'd rather see green first.
http://hg.mozilla.org/tracemonkey/rev/b583111a88aa
Whiteboard: [fixed-in-tracemonkey]
Surely some of the millions of Web pages are going to have similar problems to what we encountered in comments #27-#31? Do we really have to land this just to be sure that it breaks the Web?
Backed out for causing mochitest-browser-chrome orange in opt builds only:
http://hg.mozilla.org/mozilla-central/rev/6276eb5b2d9c


TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/components/sessionstore/test/browser/browser_500328.js | first popstate object. - Got null, expected {"obj1":1}
TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/components/sessionstore/test/browser/browser_500328.js | Test timed out
TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/components/sessionstore/test/browser/browser_500328.js | Found a tab after previous test timed out: http://example.com/?foo


(Also, I've been told Date.now() is Gecko-specific, and we haven't changed the things that are cross-browser.)
Was this ever raised on es-discuss? I don't remember seeing any Harmony proposals or discussions about this. I agree with roc. This is asking for webcompat trouble for very little value in return.
gal: see above.
I still don't see any Harmony proposal on ecmascript.org.
dherman, was this discussed at one of the meetings? I missed a few between when this bug was opened and today.
(In reply to comment #4)
> 
> Date.now() is new in ES5 so I doubt we'll break the web anyway. 

It's new to the standard, but it's been around for a while. It ships in IE9, Chrome, and Safari too. I doubt the opposite.

(In reply to comment #7)
> Maybe some of them return doubles.

None return doubles.

(In reply to comment #41)
> (Also, I've been told Date.now() is Gecko-specific, and we haven't changed the
> things that are cross-browser.)

Again, it ships in IE9 and has shipped in Chrome and Safari for years.
It looks like this will break part of MooTools 1.2, a popular JavaScript library:
https://github.com/mootools/mootools-core/wiki/Sites-using-MooTools

It uses Date.now() as a unique identifier when setting up callbacks using flashvars in its SWF embedding utility:
https://github.com/mootools/mootools-core/blob/1.2x/Source/Utilities/Swiff.js#L44
It does not expect a period to be part of Date.now() when concatenated, which causes the callback value to become invalid:
https://github.com/mootools/mootools-core/blob/1.2x/Source/Utilities/Swiff.js#L64

The development version of MooTools 2.0 has moved away from using Date.now() as an identifier, but 1.2x is still the stable version to be deployed.
(In reply to comment #47)
> It looks like this will break part of MooTools 1.2, a popular JavaScript
> library

Thanks for the heads up. We're prepared to back this out if the fallout is serious.
And merged to m-c:
http://hg.mozilla.org/mozilla-central/rev/80451fb8f11c
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
(In reply to comment #48)
> (In reply to comment #47)
> > It looks like this will break part of MooTools 1.2, a popular JavaScript
> > library
> 
> Thanks for the heads up. We're prepared to back this out if the fallout is
> serious.

This makes no sense to me. A lot of Web developers, Mozilla developers and Mozilla QA people will spend a lot of time figuring out why their stuff broke, tracing it back to this bug (or not), and then tabulating all the breakage (we won't find it all), and then we'll back this out.

It might make sense if there was a really big win here, but there doesn't seem to be.
Comment on attachment 525301 [details] [diff] [review]
Fix anything which concats Date.now() with a string

Seems like the compat risk could be mitigated if it was possible to avoid returning a float when the value is being coerced to a string. But I suspect that isn't feasible (sounds like a potential perf nightmare, at the very least).

It seems quite unlikely to me that this change is going to stick, so I'm loathe to sprinkle around these extra floor()s all over the place. I think this should just be backed out.
Attachment #525301 - Flags: review?(gavin.sharp)
Attachment #525301 - Flags: review?(dolske)
Attachment #525301 - Flags: review-
(In reply to comment #52)

Gavin, I need to apologize for landing this without your/dolske's r+. I got an rs from jwalden and felt that was sufficient, but in retrospect it was a bit thin, and it was to code that neither jwalden or I were peers to.



> Seems like the compat risk could be mitigated if it was possible to avoid
> returning a float when the value is being coerced to a string. But I suspect
> that isn't feasible (sounds like a potential perf nightmare, at the very
> least).

I agree. I'm not 100% sure this is possible, but it's definitely the wrong plan.


> It seems quite unlikely to me that this change is going to stick, so I'm loathe
> to sprinkle around these extra floor()s all over the place. I think this should
> just be backed out.

I agree that there is a high chance that this will not stick, but I would ask you to be patient in requesting this backout. We're very close to actually answering our question of "does this break the web", and we may find that we do not, in which case we can bring sub-millisecond timing to the masses.

Finally, the places that needed sprinkling are dangerous. In many cases they require that things don't happen in the same millisecond (worked around with  counter in one place!). And besides, they rely on behaviour which is not supported by the spec (though this is probably the only change which would actually trigger an error).
Having different Date.now behaviour from other browsers strikes me as a way to get a lot more noise in comparative benchmark results, a problem we already have to some degree.  (Other browsers may return the same value for consecutive calls, whereas we will return something producing a non-zero difference.)

Would making Date.nowf not suffice?  It seems like the behaviour is different enough that authors will want to opt in to the additional precision, to me.
(I should add that we already know that it'll break the web, namely any site that uses the stable version of MooTools.  I don't think we need more data to know that we'll have to back it out in order to ship FF5 on schedule, so it seems like we should do so now and gather data on trunk until libraries get updated in enough sites, we find a way to mitigate the compat issues, etc.)

Harmony specifies a nanotime or similar for higher-precision timestamps anyway, does it not?  Implementing a version of that would seem much higher value, and of lower compatibility risk.
Date.rightNow was jorendorff's suggestion, not that I want to fight a battle over it (except to say anything not interCapsy seems anomalous).

I was of the opinion that a new method was an easy way to give people what they want and avoid even the possibility of an own goal, but I wasn't *nearly* bothered enough to argue the point even slightly, and who knew, it might even work for all I knew.
OS: Linux → Windows CE
(In reply to comment #54)
> Having different Date.now behaviour from other browsers strikes me as a way to
> get a lot more noise in comparative benchmark results, a problem we already
> have to some degree.  (Other browsers may return the same value for consecutive
> calls, whereas we will return something producing a non-zero difference.)

Or, they could return a whole millisecond of difference, even though less than that has passed. This was the original motivation for this change, as one of the sunspider tests that about 0.7ms on my machine, but would constantly post as either 1ms or 0ms.
If that difference in Sunspider is even in the top 50 list of things we should be spending time on, I'll be pleasantly surprised.  Adding an alternate API and locally patching SS to use it seems like it would suffice, and avoid apples-to-oranges issues when comparing SS online between browsers.
We're retreading earlier discussion and comments here.
 - Date.now is allowed by spec to return fractional parts 
 - making it do so was a 3-line patch or so
 - that's almost no work on our part in return for higher-precision timing on websites.  And, websites could get higher-precision timing with no changes to their code.

We still want to implement Date.prototype.nanoAge or something similar.  That's a long, probably multi-month, process.

We've now seen examples of broken JS that uses Date.now() to attempt to generate unique integers.  Such code would already intermittently break before this patch, but after this patch will always break when used in eval()-like contexts.  So, this patch might (likely) have to come out.  Fine, we learned something.
(In reply to comment #55)
> (I should add that we already know that it'll break the web, namely any site
> that uses the stable version of MooTools.  I don't think we need more data to
> know that we'll have to back it out in order to ship FF5 on schedule, so it
> seems like we should do so now and gather data on trunk until libraries get
> updated in enough sites, we find a way to mitigate the compat issues, etc.)

I've nearly broken, but I spoke to cjones about this and he feels differently:

- mootools was already broken as it sometimes returned the same millisecond for consecutive call to the same function. See https://mootools.lighthouseapp.com/projects/2706/tickets/750-swiff-should-not-use-time-to-identify-callbacks

- its not all of mootools which is broken, only the Swiff submodule.

- we should let this go out in at least one nightly before we're in a good position to assess its impact. If the web breaks, we'll know tomorrow, and can make an informed decision.
(In reply to comment #60)
> If the web breaks, we'll know tomorrow, and can make an informed decision.

It often takes months to learn that something important on the web broke. Not every significant bug is noticed right away; not every noticed bug is filed with us; not every filed bug is filed in the right component, etc.

Seems ok if Moo is fixing but this one smells like it will bite back (my sense of smell is trained by ~15 years of this). We might want to spec a new method in a strawman, anyway. Allen, Dave: any new thoughts?

/be
> If the web breaks, we'll know tomorrow, and can make an informed decision.

The nightly channel has nowhere near enough users to tell anything. With FF4 a lot of webcompat issues didn't surface until RC. Our dev channels are nice to tell whether something causes problems or not, but they will often underestimate the severity of the problem and will not find what we are looking for. In this particular case we already _know_ this breaks the web (mootools). I don't think there is anything left here to look for. We have our answer. If mootools relies on this, other stuff will as well.
(In reply to comment #61)
> Allen, Dave: any new thoughts?

Not really. If the web truly relies on integers, the spec is wrong; reality is king. My sense of smell is not as highly trained, but the data don't look too good (MooTools, oranges in our own codebase). The web has seen worse cruft than two variants of Date.now().

How about accepting an optional boolean that turns on sub-millisecond timing? It's strictly cruftier than the landed patch, but only a *wee* bit cruftier (no need for a second method). And it shouldn't break the web.

Dave
> How about accepting an optional boolean that turns on sub-millisecond timing?
> It's strictly cruftier than the landed patch, but only a *wee* bit cruftier (no
> need for a second method). And it shouldn't break the web.

...unless the additional branch required will noticeably affect the timing. Dunno.

Dave
I am really opposed to adding random features without some feedback from TC39. Lets bring this up and if there is consensus, lets add it.
(In reply to comment #65)
> Lets bring this up and if there is consensus, lets add it.

What is "it"?

Dave
it == whatever TC39 agrees on
(In reply to comment #67)
> it == whatever TC39 agrees on

ITYM "===". ;-P

I haven't got a strong sense of whether the change is feasible. It's obviously preferable; it's just a question of whether we can get away with that. I defer to sayrer, dmandelin, brendan, roc, etc. on that question.

If we do need to change the API, you're absolutely right it's got to go through TC39, at least to get rough consensus. It shouldn't take too long; this doesn't seem like it ought to be super controversial on the committee. (Famous last words?)

Dave
(In reply to comment #62)
> > If the web breaks, we'll know tomorrow, and can make an informed decision.
> 
> If mootools relies on this, other stuff will as well.

We could say this about anything, and as a result I don't find this argument convincing. But to remind you, mootools does not rely on this, a submodule of mootools 1.2 relies on this. There is a world of a difference.



(In reply to comment #61)
> It often takes months to learn that something important on the web broke.

I'm not really sure how the broken site can be important if nobody realizes for months. (Or more to the point, how it can be considered broken if nobody notices). I'm not sure how we make these decisions, but it seems to me if nobody notices, we should leave this in. It is valid behaviour according to the spec after all.
> I'm not sure how we make these decisions, but it seems to me if
> nobody notices, we should leave this in.

I honestly don't know either. But I don't discount the experience of those who've been around this block before.

> It is valid behaviour according to the spec after all.

That doesn't matter. The spec is not a dictator. The spec is an artificial document on which we confer a certain amount of authority. This serves a useful purpose in getting multiple competing parties to synchronize around common goals. However, other constraints can carry just as much or more authority. This includes web users who don't know why Site X stopped working when they upgraded their browser, and are free to switch browsers.

This isn't something that can be resolved by pure logic. We have to make an educated guess about what's on the web right now. We'd like to get more scientific about making these kinds of decisions (using better empirical tools for analyzing the contents of the web), but for now we're stuck with educated guesses.

Dave
Several JS peers and super-reviewers oppose this patch. Large parts of it were landed without review by a module owner. You got an explicit review- from gavin on the patch. Why the hell is this patch in aurora? Please back it out immediately (also from central and TM). After that, we can continue this discussion, if it really has to be.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(In reply to comment #53)
> 
> Gavin, I need to apologize for landing this without your/dolske's r+. I got an
> rs from jwalden and felt that was sufficient, but in retrospect it was a bit
> thin, and it was to code that neither jwalden or I were peers to.

These patches have to come out for this reason. End of story.

I didn't like this patch much in comment 2, August 2010. That is not why this patch has to come out. We cannot short circuit review procedures, ever.
(In reply to comment #69)
> I'm not really sure how the broken site can be important if nobody realizes for
> months. (Or more to the point, how it can be considered broken if nobody
> notices). I'm not sure how we make these decisions, but it seems to me if
> nobody notices, we should leave this in. It is valid behaviour according to the
> spec after all.

Nobody codes their web page by just reading the spec.  People see what different browsers do, and they rely on them.  I know that I've wrote web pages which used Date.now in CSS styles, which break with this change in Firefox 5, like our own code did.

I don't think that anybody doubts this: this *will* break the web.

The question that you're rising is: will it break the web on websites which are highly popular?  Maybe.  Will it break the web in a way that we get a bug report as a result?  Maybe.

Let's consider some other questions: will it cause noise in input.mozilla.com feedback?  Most likely.  Is it trivial for a QA person to determine that a web site doesn't work because of this change?  No.

I think this was a change made only for matching the spec, and unfortunately I don't think that argument is strong enough.  web-compat is a serious issue, and we shouldn't intentionally break it for the sake of matching specs which are not based on reality.  Let's back this out from Firefox 5 before the first build goes out, and focus on another API which gives us the same functionality.
Whiteboard: [fixed-in-tracemonkey] → [fixed-in-tracemonkey][aurora-backout]
I'll back this out from central and tracemonkey tomorrow if nobody beats me to it (too late here, and no time to watch the tree).
(In reply to comment #75)
> I'll back this out from central and tracemonkey tomorrow if nobody beats me to
> it (too late here, and no time to watch the tree).

Thanks ehsan. I don't have level 3 access (and now we see why), though if you tell me when you're backing out, I can watch the tree.
(In reply to comment #73)
> I think this was a change made only for matching the spec, and unfortunately I
> don't think that argument is strong enough.  web-compat is a serious issue, and
> we shouldn't intentionally break it for the sake of matching specs which are
> not based on reality.

For the record, the purpose here was to bring a facility to the web which did not exist (sub-millisecond timing).
Comments 71 and 72 do not represent the facts in this bug. To avoid getting into it, here's the summary:

 - I thought I had auto-r+s from gavin and dolske (I misread their comments), and the rs was a sanity check.
 - gavin's r- came after commit
 - I wasn't (deliberately) short circuiting anything
 - up until comment 24, everything was rosy, including peer and super-reviewer support.

Please don't make out that I was ignoring rules and consensus - that's simply not true.
I backed this out of mozilla-central, as I don't think Ehsan should have to do _all_ the work. :)

http://hg.mozilla.org/mozilla-central/rev/3b5aeb2747b1
Depends on: 649735
I think we've learned from this that we need a content-visible API for generating unique IDs.
And that settles once and for all whether this breaks the web.
Status: REOPENED → RESOLVED
Closed: 9 years ago9 years ago
Resolution: --- → WONTFIX
Whiteboard: [fixed-in-tracemonkey][aurora-backout] → [aurora-backout]
(In reply to comment #80)
> I think we've learned from this that we need a content-visible API for
> generating unique IDs.

See bug 645416 for a mechanism for generating unforgeable private names. These aren't serializeable but they cover some of the use cases. A UUID generator that produces strings would give probabilistically unique ID's that are serializeable.

Dave
A follow-up bug for adding a new function (Date.nowf() or Date.rightNow() or whatever) that does provide sub-millisecond timing seems like a reasonable idea.  pbiggar, do you want to file it?
again, please coordinate with TC39 (I think they liked .nanoTime())
There is a nanoAge proposal, which is more complex than this one (for example, guaranteeing that the "age" doesn't become negative if someone changes the time on their machine).

Link: (and you can ignore the 
http://wiki.ecmascript.org/doku.php?id=proposals:date_and_time&s=nanoage#current_and_elapsed_times


This was designed to be a quick win, as it was capable of landing long before nanoAge would. However adding a new Date.rightNow or something isn't a quick win, so we should probably wait for nanoAge and do it right.
You need to log in before you can comment on or make changes to this bug.