Just raised a bug for this. Except the usage in jsCurrentTime(), all calls to currentTime() in both JavaScriptCore (threading, TimeoutChecker, ProfileNode...) and WebCore (Timer, and many other cases...) are time counting and assume it never goes backward. If we make currentTime() return the system UTC time (like gettimeofday), then it will break time counting when system time is changed (e.g. by calling settimeofday()), and give unexpected results. If we make currentTime() always increase, then after user changes system time, the browser cannot provide correct JS Date until being restarted.
https://bugs.webkit.org/show_bug.cgi?id=37743 2010/4/16 Yong Li <[email protected]> > Hi All > > The default implementation of JS Date is calling currentTime() (by > jsCurrentTime()), so it assumes currentTime() returns current UTC time, and > system UTC time can be changed. However, currentTime() is also used in most > cases as a system tick count, which means it should always be monotonically > increasing. I guess we should remove the dependency on currentTime() from JS > Date to fix the confliction. > > Any idea? > > -Yong > >
_______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
