I read RFC 7232, which describes the Last-Modified time as below:
A Last-Modified time, when used as a validator in a request, is implicitly weak unless it is possible to deduce that it is strong, using the following rules:
The validator is about to be used by a client in an If-Modified-Since, If-Unmodified-Since, or If-Range header field, because the client has a cache entry for the associated representation, and
That cache entry includes a Date value, which gives the time when the origin server sent the original response, and
The presented Last-Modified time is at least 60 seconds before the Date value.
My question is, "Why can those three conditions that Last-Modified support mean it can be strong validator?"
The section you quoted goes on to say:
This method relies on the fact that if two different responses were sent by the origin server during the same second, but both had the same
Last-Modifiedtime, then at least one of those responses would have aDatevalue equal to itsLast-Modifiedtime. The arbitrary 60-second limit guards against the possibility that theDateandLast-Modifiedvalues are generated from different clocks or at somewhat different times during the preparation of the response.
Say that we have two representations of a resource, A being the older version and B being the newer version. If they were both modified in the same second then they could both be served with the same Last-Modified time. So if all we have to go on is the Last-Modified header we don't know whether the representation is A or B. That's what makes Last-Modified a weak validator.
But let's say the cache entry also has an associated Date field, and that it's later than Last-Modified. We can now safely assume that the cache entry is B, the version that was current as of the Date time. Since we now know which version is represented by the cache entry we can treat Last-Modified as a strong validator.
(Note that the most recent standards use 1 second instead of 60.)