Firefox is not NTP synced, which causes Date.now() etc. being non-reliable for Networking

RESOLVED INVALID

Status

()

RESOLVED INVALID
4 years ago
3 years ago

People

(Reporter: u479927, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

4 years ago
User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.99 Safari/537.36

Steps to reproduce:

Set the system of a clock to 5 minutes ago.
Leave the server untouched and NTP synced.

Date.now() is now unusable for Networking, because it's non-reliable.
You manually have to implement 1. a hearbeat and tick and 2. a custom Date.now() method that respects the offset of time to the other connection, which is pretty much useless for networking (if server is still out of sync).

I expected to have a Browser that is automatically supporting NTP in the background.
Why is there no spec or draft for it? In times of WebSockets, this is a _huge_ issue.


Actual results:

Date.now() used system clock and not NTP, which caused asynchronous behaviours on server and client.


Expected results:

Date.now() should rely on NTP protocol to ensure correct system clock.

Updated

3 years ago
Component: Untriaged → JavaScript: Standard Library
Product: Firefox → Core
Why the system clock does not sync with NTP? It's the operating system job to sync the clock, not an application.

Comment 2

3 years ago
Hello Reporter, are you satisfied with Masatoshi's response. If not, do you see a different behavior with other browser's like Chrome, IE, etc. Let us know.

Comment 3

3 years ago
It seems that the reporter's account is disabled. Therefore no answer is expected. Going ahead and closing this issue as it seems an invalid defect because it should be OS job to sync the clock, not Firefox.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.