Whichever timezone is relevant to the analysis later when the data is read.

If you want to see if an employee is late compared to the time their shift starts, the system needs to know the time their shift starts in UTC, because otherwise if they start a shift in during a timezone change, it’ll think they’re extremely late/early.

If you want to pay them for their (clock out - clock in) time, UTC.

If they’re a remote worker on your team, and you want see your entire team’s availability, you should probably see it in _your_ local time instead.

I’ve found that whenever it looks like I need to know the local time that the user had when they did something, it’s because I’m implicitly anchoring it to some other timestamp that my system doesn’t know and that should also be recorded in UTC (like, in this example, the time their shift is supposed to start).

Some nuance applies, of course.