timers behavior on system time change

[VK]

This is in the connection with "DOM timers and the system clock":
http://groups.google.com/group/comp.lang.javascript/browse_frm/thread/0a3e7ebbdff15a58

Assuming

var timerID = window.setTimeout(doIt(), 20000);
executed at the moment of time 2010-XX-XX 23:50:0000

and within the next 20 secs OS time was changed by DST request or
manually. Will it be executed somewhere in 20000ms since timerID set
irrespectively to the OS time, somewhere at 2010-XX-XY 00:10:0000 of
the old system time, somewhere at 2010-XX-XY 00:10:0000 of the new
system time? Other words is the queue based on an absolute scale,
immutable time stamps, mutable time stamps?

[Boris Zbarsky]

1) This is a DOM issue, not a JSEng one.
2) Right now, the new system time would determine firing time (though
note that "time" means "time since epoch", so is unaffected by
DST changes, changes of OS timezone, or the like; only actual
changes to the actual clock matter, not to the user-visible
display).
3) The information in item 2 is subject to change. See
https://bugzilla.mozilla.org/show_bug.cgi?id=558306

-Boris

[VK]

On Jun 27, 8:31 am, Boris Zbarsky <bzbar...@mit.edu> wrote:
> 1)  This is a DOM issue, not a JSEng one.

ECMAScript is not a computationally self-sufficient language, only
JavaScript is. So the basic stuff like minimal IO (alert, confirm,
prompt), setTimeout / setInterval for JavaScript is definitely core
IMO.

> 2)  Right now, the new system time would determine firing time (though
>      note that "time" means "time since epoch", so is unaffected by
>      DST changes, changes of OS timezone, or the like; only actual
>      changes to the actual clock matter, not to the user-visible
>      display).
> 3)  The information in item 2 is subject to change.  See
>      https://bugzilla.mozilla.org/show_bug.cgi?id=558306

Thank you for your concise and informative answer.

[Wes Garland]

> So the basic stuff like minimal IO (alert, confirm,
> prompt), setTimeout / setInterval for JavaScript is definitely core
> IMO.

Not really. I use JavaScript on the server side daily without those. Also,
they are not implemented as part of the engine, but rather the DOM.

Incidentally, "funny questions" like these are exactly why we run NTP
daemons in server land to change the system time -- less worry about
seldom-seen software bugs. NTP works basically by stretching or shrinking
seconds until the system clock matches the reference clock. It's as if the
running processes experience relativistic time dilation, but cheaper than
accelerating your server to near light speed! :)

Wes

--
Wesley W. Garland
Director, Product Development
PageMail, Inc.
+1 613 542 2787 x 102

[Boris Zbarsky]

On 6/27/10 7:48 AM, VK wrote:
> On Jun 27, 8:31 am, Boris Zbarsky<bzbar...@mit.edu> wrote:
>> 1) This is a DOM issue, not a JSEng one.
>
> ECMAScript is not a computationally self-sufficient language, only
> JavaScript is.

I think you're a little confused about the situation. There are three
separate concepts at play here:

1) ECMAScript: a language specification.
2) JavaScript: a particular ECMAScript implementation, with some
extensions, which exposes a C api for embedding it.
3) JavaScript embedding of various sorts. These include the DOM
embedding in Gecko, but also many others.

> So the basic stuff like minimal IO (alert, confirm,
> prompt), setTimeout / setInterval for JavaScript is definitely core
> IMO.

You can run JavaScript in the js shell embedding that ships with
SpiderMonkey, which has none of those (but does have a print()
primitive, for example).

In Firefox, you can run JavaScript in the DOM worker embedding, in which
none of the things you listed are available (but which can do I/O via
XHR or postMessage and message handlers).

In Firefox, you can run JavaScript in a sandbox embedding in which
nothing is available from your list, no input is available, and the only
allowed output is the return value of the script. This happens for many
cases of javascript: URI usage.

Note that these last two examples are exposed to the web. There are
also various embeddings not exposed to the web (JavaScript components,
loadable modules, etc) in Firefox which have none of the things you list
but have other I/O primitives.

And of course there are many non-Firefox embeddings of JavaScript.

More to the point, if you ask a js engine hacker a question about quirks
of a particular embedding (which is what setTimeout behavior is),
chances are they have no idea what you're talking about. So such
questions are better directed to the people who created and maintain
that embedding (the mozilla.dev.tech.dom newsgroup for most of the Gecko
embeddngs). At least if you want to maximize your chance of getting a
useful answer. ;)

> Thank you for your concise and informative answer.

You're very welcome.

-Boris