Re: [xhr] Abandon hope of removing sync XHR from the web platform? (#20)

It uses human readable time zones since there is more to time zones than
offsets (different time zones can temporarily share offsets, like for
daylight savings time, then the offsets will diverge).  Moment.js does
these, but pulling in a new dependency (the quality of which I cannot vouch
for) is not as nice as changing a flag.



As for the performance.now() thing, it is certainly doable, but then we’re
adding state to a process which was previously stateless.



The “janky”ness of the re-init has more to do with how the widget’s author
implemented init than the network or the DOM.



*From:* Philip Jägenstedt [mailto:notifications@github.com]
*Sent:* Tuesday, March 22, 2016 3:29 AM
*To:* whatwg/xhr
*Cc:* Jason Stewart
*Subject:* Re: [xhr] Abandon hope of removing sync XHR from the web
platform? (#20)



What kind of date handling is done of the server that there are no good
APIs for in the browser? I guess it's not simply adding/subtracting a
timezone offset, so something to do with human readable strings like
"America/Pacific", maybe?

If you know up front the offset between performance.now() and the
server-side time in UTC, then I doubt you'd need to sync it more than say
once a week/month or so. How much does performance.now() drift, in practice?

As for just lowering the timeout, in order to ensure that scripted
animations are not janky, the timeout would have to be before the next
animation frame callback, so never more than 16ms. Even on the fastest of
networks, that's not going to be reliable.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
<https://github.com/whatwg/xhr/issues/20#issuecomment-199699712>


---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/xhr/issues/20#issuecomment-199833132