Here is a bug that almost every HR system ships at least once. An employee in Mumbai clocks in at 9:10am on a Tuesday. The attendance report shows them absent on Tuesday and present on Monday evening. Nothing was entered wrong. The clock-in was recorded accurately, to the second. And the report is still wrong.
The cause is a conversion nobody thinks about, because it looks like it has only one possible answer.
Two different kinds of time
A clock-in is an instant: a single point on a universal timeline, usually stored as a timestamp with a timezone offset. Instants are unambiguous. The moment that employee tapped the button exists once, and every system in the world agrees on it.
A working day is something else entirely. It is a calendar date — "Tuesday the 15th" — and a calendar date is not a point on a timeline. It is a label that only means something relative to a place. The same instant is Tuesday morning in Mumbai, Monday evening in New York, and Tuesday just-past-midnight in London.
Attendance software has to convert the first into the second. Every record is an instant, and every report, sheet and payroll line is organized by calendar date. That conversion is the entire bug, because it requires a timezone, and the code has to get that timezone from somewhere.
Where the wrong timezone comes from
There are only a few places the conversion can get a timezone, and most of them are wrong in a way that is invisible during development.
- The server’s timezone. Almost always UTC in a modern deployment, which means every date boundary falls at midnight UTC — 5:30am in India, 8pm the previous day in California.
- The database’s session timezone. Also usually UTC, and worse, it can differ between a connection pool, a background job and a migration.
- The viewer’s browser timezone. Tempting, and it produces a report that changes depending on who opens it — which means two managers reading the same month see different numbers.
- The employee’s own timezone. Closer to reasonable, but it makes an organization-wide sheet incoherent, because the columns no longer describe one shared day.
The correct source is none of those. It is the organization’s configured timezone — the one the business actually runs its days by. That is the only timezone under which "Tuesday the 15th" has a single agreed meaning for everyone in the workspace, which is precisely what a report needs.
Why it stays hidden for months
This bug has a particularly cruel property: it does not appear for the team that builds it. If your engineers are in UTC or close to it, and your test data is daytime office hours, every conversion lands on the day you expect. The bug only manifests for a specific combination — an organization far enough from UTC that normal working hours cross the UTC date boundary.
And even then it is quiet. An attendance record on the wrong day does not throw an error. It produces a plausible-looking report with one absence that was not real and one presence on a day nobody worked. Nobody audits that. It gets noticed weeks later, when a month-end total does not match, and by then the trail has gone cold.
The damage is downstream
If attendance were a standalone report, a one-day drift would be an annoyance. It is not standalone. The calendar day on an attendance record is a key that other things join on.
- Payroll reads hours by date range. An hour that drifted out of the month is an hour that does not get paid in that month, and an hour that drifted in gets paid twice across two cycles.
- Overtime rules apply per day or per week. A shift assigned to the wrong day can push one day over a threshold and pull another under it, changing a figure in both directions at once.
- Leave has to agree with attendance. An approved day off and a missing attendance record should describe the same date. If they are computed in different timezones, they sometimes do not, and someone has to decide which record is lying.
- The shared calendar shows the same days to everyone. An event on one date in the calendar and another in the attendance sheet makes both untrustworthy.
This is why the fix cannot be a patch on the report. The date has to be right where it is recorded, so that everything joining on it inherits a correct value rather than each module applying its own correction.
What OneclickHR does
Every OneclickHR workspace has an organization timezone, set during setup, and it is the authority. An attendance record carries both the instant it happened and the calendar day it belongs to, and that day is derived from the organization timezone — not the server’s, not the browser’s, not the database session’s.
The same setting governs leave dates and calendar events, so the three agree by construction rather than by reconciliation. When the payroll review step shows you an hours total you did not expect, you can follow it back to a specific day on a specific attendance sheet, and that day means what you think it means.
What to check in any system you evaluate
If you are assessing HR software, this is a five-minute test that tells you a lot about the care underneath. Ask these three questions.
- Where does the organization timezone live, and is it one setting or several? If attendance, leave and the calendar each have their own notion of a day, they will eventually disagree.
- If I clock in at 9am local time, which calendar date does the record carry? Ask them to show you, with an organization timezone far from UTC.
- When the clocks change for daylight saving, what happens to the day boundary and to a shift that spans it? A system that has thought about this has an answer ready.
A vendor who has dealt with this will answer quickly and specifically, because it is the kind of problem you only solve once but never forget. A vendor who has not will tell you timestamps are stored in UTC, which is true, and which is not an answer to the question.
Storing instants in UTC is correct and insufficient. The question is which timezone you convert them back in, and whose day that produces.
Attendance is the least glamorous module in any HR system. It is also the one every other module depends on for its dates, which makes it the place where a quiet correctness decision has the loudest consequences.