Very often, between all of my sites on Netlify, I will hit a front end server whose time is way off. Sometimes more than a week.
Could you implement ntp or some other system to keep all the cattle clock up to date?
Hi @tilsammans,
Not sure what you mean and I’m not too sure on your workflow. But, in short, you can grab the time in JS:
// Provide the current date
var time = new Date().toLocaleString()I mean the date in the http response headers. For some requests, these are way off. It usually means the web server in question is misconfigured. It’s not a huge deal but some SEO/analytics applications show a warning.
To further illustrate my point, consider this terminal output, which I copied verbatim:
for i in {1..5}; do curl --no-progress-meter -I https://www.spacebabies.nl | grep date; done
date: Sat, 01 Aug 2020 10:50:57 GMT
date: Sat, 01 Aug 2020 10:50:57 GMT
date: Tue, 28 Jul 2020 01:47:50 GMT
date: Sat, 01 Aug 2020 10:50:57 GMT
date: Tue, 28 Jul 2020 01:47:50 GMTHey @tilsammans,
I believe these times are relative to when the CDN node cached the content. You may contact a different PoP for each request, hence the discrepancy.
You could add a custom header to grab the current time.
Hi Pieparker,
No, that is not correct.
Could you escalate this issue or assign it to someone else please? There is a knowledge gap here that I am not sure I will be able to bridge. I am not in need of a custom header or the current time at all. I am simply informing you that some CDN nodes are misconfigured, which is a violation of spec.
What you are referring to is the Last-Modified header, which is set correctly.
The Date header represents the date and time at which the response was originated. There is no room for interpretation here, it’s right there in RFC 2616 paragraph 14.18.
If the issue will not be resolved I suggest we close the topic.
Happy to escalate this, if necessary.
However, reading the specification:
The “Date” header field represents the date and time at which the message was originated
Furthermore, a bit more reading material over at W3 (Caching in HTTP):
13.1.1 Cache Correctness
A correct cache MUST respond to a request with the most up-to-date response held by the cache that is appropriate to the request (see sections 13.2.5, 13.2.6, and 13.12) which meets one of the following conditions:
It has been checked for equivalence with what the origin server would have returned by revalidating the response with the origin server (section 13.3);
It is “fresh enough” (see section 13.2). In the default case, this means it meets the least restrictive freshness requirement of the client, origin server, and cache (see section 14.9); if the origin server so specifies, it is the freshness requirement of the origin server alone.
If a stored response is not “fresh enough” by the most restrictive freshness requirement of both the client and the origin server, in carefully considered circumstances the cache MAY still return the response with the appropriate Warning header (see section 13.1.5 and 14.46), unless such a response is prohibited (e.g., by a “no-store” cache-directive, or by a “no-cache” cache-request-directive; see section 14.9).
- It is an appropriate 304 (Not Modified), 305 (Proxy Redirect), or error (4xx or 5xx) response message.
So, given you have a Cache-Control header of max-age=60, besides whatever local caching is at play, and the content remains unchanged, the request is still fresh and the date won’t be revised.
Happy to discuss any misconception I may have here or, as I said at the beginning, get more eyes on the topic for you!
1 Like
Hi @tilsammans , @Scott is right, the date header corresponds to the date when the CDN server cached the content.
BUT (and this is a big but) @Scott, a “good” CDN would send the current date. You can read here Forums | AWS re:Post why it’s problematic regarding client caching (due to this, browsers tend to not use local cache correctly, which increases TTFB). From my tests, Firebase Hosting and Stackpath return the current Date while Cloudfront and Netlify return the cached Date, which increase TTFB and bandwidth for assets like Javascript and images.
Combined with the fact that Netlify use the same CDN cache from free to business users, it reduces the competitivity of Netlify for Pro and Business users.
So @Scott I would love if we can have a discussion about Netlify changing this behavior regarding the returned date (maybe with a configuration field in netlify.toml, for backward compatibility) in order to reduce TTFB and bandwidth 
I appreciate the discussion! I ran this by the applicable internal team and, as a result, I’ve raised the feature request for discussion. If/when we know more, we’ll let you know 
!
1 Like
Hi, any development on this? I see the clock is still incorrect, at least that’s what the SEO tools say.
hi @naton , I am asking the team to see if we have any updates on this. I’ll let you know what we hear back!
2 Likes
Hey, are they any news on this topic? I’m also interested in a solution.
iya! Nothing to present just yet however it’s likely that this will be bundled up with other, ongoing project works. We’ll update the post once we know more!
2 Likes
Hi @Scott , did anything ever come from this? I found this topic searching about the exact same issue, as it has been flagged up by an SEO audit. Thanks!