Re: [Gnumed-devel] server-client clock mismatches

[James Busser]

On 9-May-08, at 8:45 AM, Karsten Hilbert wrote:

> The log indicates that client and server are off by roughly
> one minute which isn't a whole lot.
>
> What would people consider a reasonable boundary condition ?
> 1 minute, 2 minutes, 5 minutes ?

Vancouver and Germany (where I presume the server to reside) were  
"off" by 55 seconds, and reside at a distance (separation) of about  
8,000km

Canberra / Melbourne are at a distance of about 16,000km

Therefore if the purpose is to avoid inhibiting connections to the  
test server from anywhere in the world, at least 2 minutes would be  
required, and 3 minutes would be safer.

The clinical importance of such things is in the real-time ability  
for people to see what is happening (which GNUmed supports, within  
whatever latency will allow) and also how the event was recorded. If  
users A and B were both accessing a single patient's record at the  
same time (as could happen during a phone call), it is possible both  
"write" to the record in quick succession (within a minute or two of  
each other). But what is important is not whether the timestamps were  
off by 2 minutes vs 4 minutes but the fact that two records committed  
in close sequence may get stored, and viewed, and presented in an  
inverse order to their real occurrence.

If I connected remotely and am recorded to have "signed" a patient  
chart entry at 20080509 at 11:00:00h, and shortly thereafter but  
unknown to me a local lab handler imports lab results, and assigns  
them an import time of 10:58:00 (making them appear to have been  
available two minutes prior to my finishing what I had done) I am  
still not sure I see a problem. Yes, if would come out to the main  
screen, I could see some message that these records are now in the  
system magically stamped as 1-3 minutes older than I may like. But  
even if I now sign them, won't the datetime stamp of signing be  
determined by my client, which would would maintain an audit of my  
activity as sequential?

I suppose if the records were assigned a later datetime stamp of  
creation and a person tried to sign them with an earlier datetime  
stamp that might trigger an error depending on the backend table  
constraints.