I'm writing an app to track employee work activity. Employees can use the app to record "working on job 123" or "in Training" or "Cleaning work area", etc.

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).

Imagine this scenario:
User logs in at 8am
Server time is also 8am, device and server are in sync
User starts work on Job 123
at 9am user changes device clock to 8:30
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

Best way I see to solve this is to get the server time when app starts up and then use GetDeviceTicks to calculate current server time.

The main problem with this is device might not be able to connect to the server when it starts up, and not retrieve server time, but they still need to use the app.

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. Thank you.

Keith wrote:

> By your post are you saying that mobile devices always have
> access to GPS, even when they don't have data services? If so
> that is news to me, and might be a great solution. I will look at
> the GPS example, when I tried it a year ago it did not work well
> for me for some reason. If mobile devices always have access to
> GPS, and GPS provides a time stamp, then that solves my problem!

GPS is not always available, even if the device hardware supports it.  Sometimes 
a GPS signal is simply blocked by buildings, weather, etc.  And worse, some 
devices may cache and report the last known GPS information when no signal 
is immediately available.

-- 
Remy Lebeau (TeamB)

By your post are you saying that mobile devices always have access to GPS, even when they don't have data services? If so that is news to me, and might be a great solution. I will look at the GPS example, when I tried it a year ago it did not work well for me for some reason. If mobile devices always have access to GPS, and GPS provides a time stamp, then that solves my problem! I will test.

> {quote:title=Gilbert Padilla wrote:}{quote}
> I'm assuming your app is used in a mobile device that has access to GPS as 
> most devices do, also the user has to check-in and check-out of a job.

I'm assuming your app is used in a mobile device that has access to GPS as 
most devices do, also the user has to check-in and check-out of a job.


>>- the device might be unable to connect to the network/server for several 
>>days

Most likely the mobile device could be GPS enable, so it doesn't need to be 
online or connected to a server to get a time stamp and location from the 
satellite wich the user is unable to change

>>- the user can change the device time

If you get the check-in time and check-out time from the GPS, and even the 
time stamp from the device then you would have a way to verify that the user 
did not change the time in the device
since the elapsed time should match.

>>- my app is not always on

No problem. The GPS system is always on, check the firemonkey Location 
Sensor component

Keith wrote:

> - the device might be unable to connect to the network/server
> for several days

Then the server loses the ability to trust the client's input.

> - the user can change the device time
> - my app is not always on

Then the app loses the ability to trust the user's input. 

> In that scenario, I don't believe there is a way to know that the
> times reported from the app are accurate.

Nope.

> An employee working out of town might change the device time
> during the course of the day, by a few minutes or by an hour or
> more

Why?

> and it would be wrong to pay him less or more than he should have
> earned.

If the device clock cannot be trusted, then the client/server will have to 
rely on an external clock that the user cannot mess with.

-- 
Remy Lebeau (TeamB)

Here is the situation:

- the device might be unable to connect to the network/server for several days
- the user can change the device time
- my app is not always on

In that scenario, I don't believe there is a way to know that the times reported from the app are accurate.

Part of this is a trust issue, but part is accuracy and fairness. An employee working out of town might change the device time during the course of the day, by a few minutes or by an hour or more, and it would be wrong to pay him less or more than he should have earned.

>>The main problem with this is device might not be able to connect to the 
>>server when it starts up, and not retrieve server time, but they still 
>>need to use the app.

>>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. Thank you.

Probably a GPS Clock Synchronization may work

Same can be done with date and time or time alone.
Sheduled task Midnight for Date and maybe for time every hour.
To check date and/or time on server from client takes <1 sec.
Only if there was tampered with, client will see or better wont have to,send 
email to admin@ to inform about it.

Hope this is alright.

"Lieven Vandaele"  wrote in message 
news:710076@forums.embarcadero.com...
> Hi Keith
>
> 01/18/15  this is sample of date.txt you could use on client side or 
> severside
>
> For serverside you mite need date.exe there who is executed at midnight 
> everyday onserver and make the server date.txt.
> I have uploaded in the attachment group date.zip .
>
> {delphicode}//serverside or ??clientside
>
>
> assignfile(t, ExtractFilePath(ParamStr(0))+'date.txt');//t = var 
> t:textfile st:string
>    try
>      reset(t);
>      readln(t,st);//
>    finally
>      closefile(t);
>    end;
>
>    ShortDateFormat := 'MM/dd/yy';
>    if date <> StrToDate(st) then begin // now you can lock the program 
> with hiding forms this until date= StrToDate  etc...
>     // ShowMessage('The date on your computer is incorrect.  Please 
> rectify and try the Send again');
>      ShortDateFormat := 'dd/MM/yyyy';
>      //fmdiary.uploaded := 0;
>      Exit;//
>    end;
>
>
> {code}
>
>
>
>
> "Eduardo Elias" <@> wrote in message news:710042@forums.embarcadero.com...
>> 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.

Sorry again but let me wrap this up and please let me know if this can be 
done with firemonkey aswell, don't have firemonkey.

The date.exe looks like follows, incase the date.zip does not download.

This way I think you are incharge from client and or server anytime.

{delphi code}

//Date.pas
unit Date;

interface

uses
  Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms, Dialogs,
  ExtCtrls;

type
  TForm1 = class(TForm)
    Timer1: TTimer;
    procedure FormActivate(Sender: TObject);
  private
    { Private declarations }
  public
    { Public declarations }
  end;

var
  Form1: TForm1;

implementation

{$R *.DFM}

procedure TForm1.FormActivate(Sender: TObject);
var
  t:textfile;
begin
  assignfile(t,extractfiledir(paramstr(0))+'\date.txt');
  rewrite(t);
  ShortDateFormat := 'MM/dd/yy';
  writeln(t,datetostr(date));
  closefile(t);
  close;
end;

end.

//Date.dfm

object Form1: TForm1
  Left = 192
  Top = 121
  Width = 182
  Height = 83
  Caption = 'Date'
  Color = clBtnFace
  Font.Charset = DEFAULT_CHARSET
  Font.Color = clWindowText
  Font.Height = -11
  Font.Name = 'MS Sans Serif'
  Font.Style = []
  OldCreateOrder = False
  OnActivate = FormActivate
  PixelsPerInch = 96
  TextHeight = 13
  object Timer1: TTimer
    Enabled = False
    Interval = 600000
    Left = 16
    Top = 8
  end
end

//Date.dpr

program Date;

uses
  Forms,
  date1 in 'date1.pas' {Form1};

{$R *.RES}

begin
  Application.Initialize;
  Application.CreateForm(TForm1, Form1);
  Application.Run;
end.

"Lieven Vandaele"  wrote in message 
news:710076@forums.embarcadero.com...
> Hi Keith
>
> 01/18/15  this is sample of date.txt you could use on client side or 
> severside
>
> For serverside you mite need date.exe there who is executed at midnight 
> everyday onserver and make the server date.txt.
> I have uploaded in the attachment group date.zip .
>
> {delphicode}//serverside or ??clientside
>
>
> assignfile(t, ExtractFilePath(ParamStr(0))+'date.txt');//t = var 
> t:textfile st:string
>    try
>      reset(t);
>      readln(t,st);//
>    finally
>      closefile(t);
>    end;
>
>    ShortDateFormat := 'MM/dd/yy';
>    if date <> StrToDate(st) then begin // now you can lock the program 
> with hiding forms this until date= StrToDate  etc...
>     // ShowMessage('The date on your computer is incorrect.  Please 
> rectify and try the Send again');
>      ShortDateFormat := 'dd/MM/yyyy';
>      //fmdiary.uploaded := 0;
>      Exit;//
>    end;
>
>
> {code}
>
>
>
>
> "Eduardo Elias" <@> wrote in message news:710042@forums.embarcadero.com...
>> 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.

Oh this is firemonkey group, maybe the code given does not work there.lol
Not to sure, try.
Sorry for that.

"Lieven Vandaele"  wrote in message 
news:710076@forums.embarcadero.com...
> Hi Keith
>
> 01/18/15  this is sample of date.txt you could use on client side or 
> severside
>
> For serverside you mite need date.exe there who is executed at midnight 
> everyday onserver and make the server date.txt.
> I have uploaded in the attachment group date.zip .
>
> {delphicode}//serverside or ??clientside
>
>
> assignfile(t, ExtractFilePath(ParamStr(0))+'date.txt');//t = var 
> t:textfile st:string
>    try
>      reset(t);
>      readln(t,st);//
>    finally
>      closefile(t);
>    end;
>
>    ShortDateFormat := 'MM/dd/yy';
>    if date <> StrToDate(st) then begin // now you can lock the program 
> with hiding forms this until date= StrToDate  etc...
>     // ShowMessage('The date on your computer is incorrect.  Please 
> rectify and try the Send again');
>      ShortDateFormat := 'dd/MM/yyyy';
>      //fmdiary.uploaded := 0;
>      Exit;//
>    end;
>
>
> {code}
>
>
>
>
> "Eduardo Elias" <@> wrote in message news:710042@forums.embarcadero.com...
>> 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.