assuming that your program will have PUNCH IN and PUNCH OUT buttons, then a timeclock table with user id, punch-in, and punch-out fields is a good approach
you could model this using an event table as suggested by others, but the problem with that model is that you either have to have a Type field (in or out) or you have to try to figure out if the user is punching in or out; might as well put it all in one row - that way if someone tries to punch out but never punched in, it is a trivial query to figure that out and you don't have to fool with two records and a type for each in-out pair
summary: one table with in/out dates is less storage and simpler queries
note that modeling individual clock-punch events not only requires an additional (wasteful) event-type field, it complicates processing unnecessarily, and introduces a 1:1 relationship between records that can only be found by temporal comparison
EDIT: at this point we don't really know whether the OP is using a dumb punch-clock device, or a smart punch-clock program. If the former, then there is no choice but to record punch events and reconcile later; if the latter, reconciliation/detection can occur when the punch happens.
