Closed Bug 1397061 Opened 2 years ago Closed 2 years ago

Firefox incorrectly says my system date is wrong


(Cloud Services :: Server: Remote Settings, defect)

Not set


(firefox62 fixed)

Firefox 62
Tracking Status
firefox62 --- fixed


(Reporter: ashish, Assigned: leplatrem)




(3 files)

Opening shows:

> Your computer is set to 9/5/17, when it should be 9/3/17. To fix this problem, change your date and time settings to match the correct time.

However, my system date is correct:

> $ date
> Tue Sep  5 16:33:31 PDT 2017

Following a discussion on #moco, :MattN suggested opening this bug along with a screenshot of services.blocklist.* from about:config.

Running Nightly 57.0a1 on macOS 10.12.6, build ID 20170905100117.
That's a big clock_skew_seconds, isn't it?
> That's a big clock_skew_seconds, isn't it?

50 hours, that could explain the 2 days differences...

We experiences some issues with the CDN in the past but it is not supposed to cache for more than a few hours.

The blocklist checks timestamp looks good:

>>> Date(1504449)
>>> "Wed Sep 06 2017 10:27:25 GMT+0200 (CEST)"
Err the timestamp is 3/9/2017 à 16:39:42 

So it is possible that the clock_skew_seconds was calculated from this last checked timestamp.
Assignee: tarek → rhubscher
Duplicate of this bug: 1361090
:Ashish could you try to run the following command from a terminal:

curl -s -i --compressed | grep '^Date: '
Attached image clock_skew.png
Here I have a clock_skew of 45 seconds
(In reply to Rémy Hubscher (:natim) from comment #5)

> $ curl -s -i --compressed | grep '^Date: '
> Date: Wed, 06 Sep 2017 16:06:27 GMT

About a day later, the timestamps are still the same... Does that mean my browser isn't updating the blocklist?
It is possible, I will needinfo Mat and Mark that might know more about it.

In the meantime, you can use this add-on to force refresh the blocklist:
Flags: needinfo?(mgoodwin)
Flags: needinfo?(mathieu)
See Also: → 1412686
The clock skew is computed using the server date of

Since this service is running through a CDN, the Date header shifts along caching. 

If we setup CDN to have a TTL of 1 hour, the clock skew will be at most 1H on clients.

Mark, is it acceptable?

Wei, can you please tell us the currently configured TTL? 

Otherwise, we might have other services that we could rely on to obtain a reference date.
Flags: needinfo?(mathieu) → needinfo?(wezhou)
The CDN cache for has the following TTL values:

* Minimum TTL: 60
* Maximum TTL: 3600
* Default TTL: 300

The document about these values is in [1].

tldr is that if the app doesn't provide HTTP headers such as Cache-Control max-age, Cache-Control s-maxage, or Expires, then cloudfront uses the default TTL, which is 300 seconds. If the app does provide those headers, then cloudfront takes into consideration the minimum TTL, the maximum TTL and the headers in order to determine how long it caches. Generally it won't cache more than maximum TTL (There is a table that documents how the actual TTL is calculated in [2]).

Flags: needinfo?(wezhou)
OK thanks!

So, what we should do, when computing the client clock skew is to take into account the ``Age`` header, which gives us the age in seconds. 

I'll submit a patch.
Depends on: 1454970
Comment on attachment 8982042 [details]
Bug 1397061 - Adjust clock skew according to CDN cache age

Attachment #8982042 - Flags: review?(mgoodwin) → review+
Flags: needinfo?(mgoodwin)
Keywords: checkin-needed
Assignee: rhubscher → mathieu
Target Milestone: --- → Firefox 62
Version: unspecified → Trunk
Pushed by
Adjust clock skew according to CDN cache age r=mgoodwin
Keywords: checkin-needed
Backed out changeset 633f31aef218 (bug 1397061) for X clock skew failures on a CLOSED TREE
Problematic push:

[task 2018-06-06T15:05:49.772Z] 15:05:49     INFO -  TEST-PASS | services/crypto/tests/unit/test_utils_sha1.js | took 7325ms
[task 2018-06-06T15:05:51.647Z] 15:05:51     INFO -  TEST-START | services/settings/test/unit/test_remote_settings.js
[task 2018-06-06T15:07:01.111Z] 15:07:01     INFO -  TEST-PASS | services/settings/test/unit/test_remote_settings.js | took 69463ms
[task 2018-06-06T15:07:02.986Z] 15:07:02     INFO -  TEST-START | services/settings/test/unit/test_remote_settings_poll.js
[task 2018-06-06T15:07:23.841Z] 15:07:23  WARNING -  TEST-UNEXPECTED-FAIL | services/settings/test/unit/test_remote_settings_poll.js | xpcshell return code: 0
[task 2018-06-06T15:07:23.842Z] 15:07:23     INFO -  TEST-INFO took 20855ms
Flags: needinfo?(mathieu)
I modified the test to be less fagile and subject to timing.

Tests now pass
Flags: needinfo?(mathieu)
Keywords: checkin-needed
Pushed by
Adjust clock skew according to CDN cache age r=mgoodwin
Keywords: checkin-needed
Closed: 2 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.