On 18/01/2015 18:22, Keith Marbach wrote:
> I just want to thank both of you for your thoughtful responses. There is much to think about and your input much appreciated. Keith

Did anyone suggest NTP:

   http://www.satsignal.eu/ntp/setup.html

Maybe useful, maybe not.

-- 
David
Web: http://www.satsignal.eu

I just want to thank both of you for your thoughtful responses. There is much to think about and your input much appreciated. Keith

Giving some ideas:

I am doing work similar to this. You cannot rely on the local time, since 
it get easily out of sync and in most of the platform is not permited the 
application to correct the local clock.

Like was said, better to be based on the server timestamp when saving the 
record on the table.

However consider this:

If you get the information offline then you can keep the amount of time worked. 
And that needs to be measured by the device using the local time. That is 
a reliable information and you will know how much time were used (of course 
again the worked can cheat that, can start a work on the device and keep 
sleeping.... but...)

Then when you connect to the server you compare the date/time from the server 
and your local date/time and get the difference. Based that you can post 
on the server the real value based on the server clock. Since the amount 
of work based in hours will be basically correct, you need to adjust the 
clock differences.

You should use a webservice for that. If you are using a SQL server connection 
only you can create a table when you save a record with timestamp then you 
retrieve this record to get the current date/time from the server. Sure, 
that is not precise, and you need to make it short enough to post and get 
the information quickly and reduce the delay. But for this kind of purpose 
I belive you get no more than 1 second of delay for this short operation. 
Do not forget to delete this record after use (or could keep it and always 
update when needed?)

If your client is going to manually enter date and amount of worked hours 
there is nothing to be done, it is based on trust. Otherwise if you are going 
to provide a tracked app that the client click to start working and then 
click again when finishing the work then you can track that, even not online, 
using what I said.

Have fun,

Eduardo


> Keith wrote:
> 
>> I'm finding it won't be an easy thing to make sure my times are
>> correct, if the device owner can change the time on the device (in
>> settings).
>> 
> Most OSes have security policies to prevent that.  Also, Windows at
> least has a WM_TIMECHANGE notification when the system clock changes,
> which your app can listen for an act accordingly if it happen.
> 
>> User logs in at 8am
>> Server time is also 8am, device and server are in sync
> Are you using a time sync server to ensure that?
> 
>> at 9am user changes device clock to 8:30
>> 
> That is something you should try to prevent, if your OS supports it.
> 
>> User then clicks to change work activity to cleaning
>> System will think the user worked 30 minutes on Job 123 when in
>> fact he worked an hour
> Rather than allow the client to specify a timestamp at all, you could
> have the server use its local own clock for everything, and treat
> everything in UTC so you don't have to deal with timezones, daylight
> savings, etc.  Then the user cannot submit fake timestamps.
> 
> Otherwise, if the client is allowed to send a timestamp in each
> message, at least the server cancheck if the client is initially in
> sync with the server at login time and can very if the client is still
> in sync on each message received.  The client would have to send two
> timestamps in each message - its current clock time, and the time of
> the activity being reported.  But what's to prevent the client from
> lying about its activity time as long as it is <= the clock time it
> reports?  Nothing.
> 
>> Any ideas are appreciated for a good way to ensure timestamps of work
>> activity are accurate, even if device cannot connect to server for
>> several days.
>> 
> If the client is allowed to submit activity days after the fact, then
> you
> pretty much lose any hope of validating timestamps.  Who is to say the
> client
> is not lying about its work while the connection to the server was
> down?
> The server has to trust the client to tell the truth.  Timestamp
> validation
> only works when it can be done in real time.

Keith wrote:

> I'm finding it won't be an easy thing to make sure my times are
> correct, if the device owner can change the time on the device
> (in settings).

Most OSes have security policies to prevent that.  Also, Windows at least 
has a WM_TIMECHANGE notification when the system clock changes, which your 
app can listen for an act accordingly if it happen.

> User logs in at 8am
> Server time is also 8am, device and server are in sync

Are you using a time sync server to ensure that?

> at 9am user changes device clock to 8:30

That is something you should try to prevent, if your OS supports it.

> User then clicks to change work activity to cleaning
> System will think the user worked 30 minutes on Job 123 when in
> fact he worked an hour

Rather than allow the client to specify a timestamp at all, you could have 
the server use its local own clock for everything, and treat everything in 
UTC so you don't have to deal with timezones, daylight savings, etc.  Then 
the user cannot submit fake timestamps.

Otherwise, if the client is allowed to send a timestamp in each message, 
at least the server cancheck if the client is initially in sync with the 
server at login time and can very if the client is still in sync on each 
message received.  The client would have to send two timestamps in each message 
- its current clock time, and the time of the activity being reported.  But 
what's to prevent the client from lying about its activity time as long as 
it is <= the clock time it reports?  Nothing.

> Any ideas are appreciated for a good way to ensure timestamps of
> work activity are accurate, even if device cannot connect to server
> for several days.

If the client is allowed to submit activity days after the fact, then you 
pretty much lose any hope of validating timestamps.  Who is to say the client 
is not lying about its work while the connection to the server was down? 
 The server has to trust the client to tell the truth.  Timestamp validation 
only works when it can be done in real time.

-- 
Remy Lebeau (TeamB)