The Last-Modified timestamp must match the Date value returned in the response headers from the successful PUT request.
As far as I know, this is clearly not documented, but it can be obtained from documented evidence.
When you rewrite an object, itβs not the rewrite itself, which can be delayed by the final consistency model β it is the availability of the rewritten content in this S3 node (S3 is replicated to several nodes in the S3 area).
The Last-Modified timestamp, like the rest of the metadata, is set during the creation of the object and unchanged after that.
This, in fact, is not the "modification time" of the object, this is the time the object was created. The explanation may sound pedantic, but it is accurate in the strict sense: S3 objects and their metadata cannot be changed at all, they can only be overwritten. When you βoverwriteβ an object in S3, what you are actually doing is creating a new object, reusing the old key of the object (path + file name). The availability of this new object for a given S3 node (replication) is something that can be delayed by the final consistency model ... not actually creating a new object that overwrites the old ... therefore, there would be no reason for Last-Modified to which Replication latency affects (provided that there is replication latency - possible consistency may be indistinguishable from immediate consistency from time to time).
source share