client_modified and server_modified values sometimes differ by 1 second on successful upload

Thank you for the reply, Greg-DB ! Reading the API documentation I thought that if you do not explicitly set the client_modified timestamp then it will be set automatically concurrently with the server_modified timestamp when the file is committed to the Dropbox filesystem, so I expected them to always be the same. But from your reply I gather that the process goes roughly like this:

1. initiate upload -->> 2. upload binary data -->> 3. client reports upload complete and sets client_modified timestamp -->> 4. server hashes the data, commits it to filesystem and sets server_modified timestamp when it's done with processing

I guess that there is a half second delay or so between 3. and 4., thus depending on the exact upload completion time it appears to either fall on the same second or the next one due to timestamp granularity not going beyond 1 second. For example, if client_modified value was let's say T02:10:02.100 and server_modified T02:10:02.600 then both "modified" timestamps would appear the same when rounded up to 1s, but in case of my example upload above it might have been something like client_modified T02:10:02.900 and server_modified T02:10:03.200.

Is my thinking correct?