Child Item

client_modified wrong date

I'm using the Dropbox API endpoint "list_folder" to get some file information, and some have the "client_modified" value very wrong, one of the examples is this:

{
    "entries": [
        {
            ".tag": "file",
            "name": "-----.Zip",
            "path_lower": "/-----.zip",
            "path_display": "/-----.Zip",
            "id": "id:-----",
            "client_modified": "2038-01-19T03:14:07Z",
            "server_modified": "2024-03-18T16:59:39Z",
            "rev": "613f248841bbf5a8d0a0a",
            "size": 1243946,
            "is_downloadable": true,
            "content_hash": "cf5afda0631632b1a4c3520mb52031d6531c090e37c16be0dcf"
        }
    ],
    "cursor": "8LVAltTbbQqgSh5Hqiz4YFUZpRHC1U5YIkivBjOFE5tpk5OIgvmYVwUw",
    "has_more": true
}

These files are uploaded using the Dropbox client for Windows.
What could cause such a big difference between these dates?

Find more posts tagged with

Developers

Comments

Здравко

@tuliodepadua wrote:
...
What could cause such a big difference between these dates?

In general those dates are different things @tuliodepadua. 😉 You should NOT expect server_modified and client_modified to be the same!

'server_modified' is guaranteed monotonic time that's server generated. On other side 'client_modified' is a time that match (or can at least) to real modification time of particular file. When not explicitly set, 'client_modified' is set to 'server_modified' server side.

Hope this clarifies matter.

Greg-DB

The client_modified time can be set arbitrarily by the uploading client, so it can contain a significantly different datetime than server_modified. In particular, I believe the Dropbox desktop client takes the local modified time from the filesystem for client_modified when uploading the file.

In this case, it seems that whatever wrote that file to the local filesystem originally committed it with a future local modified time, and then the Dropbox client accordingly uploaded the future value.