SlidesClockThe problem in one sentence
A phone’s clock is a setting the phone’s owner can change. If the recorded start of a shift is whatever the handset reported, then the recorded start of a shift is whatever the employee’s settings app said at the time.
Nobody has to be dishonest for this to cause trouble. A phone with an incorrect timezone, a device that has not synced after a flight, or a handset with automatic time switched off will all produce records that are quietly wrong.
What server time means
The app sends a request saying "this person is clocking in now". The server decides what "now" is, using its own clock, and stores that. The phone contributes the intent; it does not contribute the time.
The displayed time is then converted into the workplace’s timezone, so a manager reviewing a shift sees the working day as it happened at that site rather than in UTC or in the reviewer’s browser timezone.
Why the workplace timezone matters too
A company operating across timezones has to decide what a working day is. If attendance is read in whatever timezone the reviewer happens to be in, the same shift appears on different dates to different people, and a month-end report depends on who ran it.
Attaching the timezone to the workplace rather than to the viewer removes that entire class of disagreement.
The related decision: never overwriting the original
Server time makes the first record trustworthy. Keeping the original record makes the history trustworthy.
Missed clock-outs happen constantly — a phone dies, someone forgets. The right handling is a correction that is requested with a reason, reviewed by a manager, and stored beside the original event rather than replacing it. The record then shows both what was captured and what was agreed afterwards.
A system that silently edits the original loses the one thing an attendance record is for.
What goes wrong in practice
The failures caused by phone-clock timestamps are rarely dramatic, which is exactly why they persist. They look like ordinary data problems until somebody traces one back.
A shift that appears to start before the employee left home. An overnight worker whose hours land on the wrong date after a timezone change. A month where one branch reports systematically early arrivals because a batch of handsets shipped with automatic time switched off. Each of these is indistinguishable from a genuine attendance pattern until you know to look for it.
The cost is not only the wrong numbers. It is that once anyone has reason to doubt the records, every dispute becomes an argument about the system rather than about the shift.
What this does not protect against
Server time fixes when an event was recorded. It does not establish who sent it or where they were — that is what verification policies are for, and the two are separate questions worth keeping separate.
A system with perfect timestamps and no verification records exactly when somebody pressed a button from their sofa. A system with strong verification and phone-clock timestamps records that the right person was at work at a time they chose. You need both, and most buyers only ask about the second.
How to check
Ask the vendor two questions. Where does the timestamp come from? And what happens to the original event when a correction is approved?
If you have a trial, there is a more direct test: change your phone’s clock by an hour and clock in. If the recorded time moves, the record is a setting.