I'm writing some code that needs to know how much out of sync the client and the single server's time are.
I'm trying to do it by creating a temp file on a SMB share hosted on the server and reading of its last modified time. I thought (maybe incorrectly) that the timestamp would be generated by the server and not the client. since it seemed like the client could really mess things up otherwise.
Can someone confirm this behaviour or come up with a different way of doing this?
Why not get the epoch time on the client and send that to the server when the client starts communication with the server, no need for smb share then. By comparing the epoch time against one another you will have your time offset in seconds. Can use rest/soap, socket, etc to communicate this between the client and server depending on what your client/server model looks like.
I guess the variable latencies involved (such as IO) here are the key issue. How fine a measure are you looking for? I am also not sure this is (strictly speaking) related to Java.
In any event, I think you need a comparative operation.
Two distinct machines are writing to a shared device (your SMB) and each creates a file which contains their epoch. Ideally, to minimize latency issues, you would want to obtain this epoch obtained just before you write and then immediately close the file.
The client then compares its own epoch and file timestamp to the server's file and its epoch content. These 4 measures should provide sufficient information to gain insight regarding the relative diff between the two JVM's epoch time.
[Edit to clarify]
For example, the server's tuple is ({epoch, ts}): {S_t, SMB_ts}, and the client {C_S_t, SMB_C_ts}. Lets say you get (funny numbers here) {5000, 4800} and {5100, 5000}. Take the diff between server's timestamp and client's stamp (here 4800 - 5000 => -200), and add to the client's epoch (here 5100+(-200)=>4900). So the client is 100 units behind the server.
[Final edit]: (Note that you have 3 clocks to deal with here: SMB's, servers', and the client's.)
You could synchronize both against a common NTP server and not worry about it. Added bonus of having a (more) correct clock!