Kronos Timekeeper and Daylight Savings Time Solved
Is this what you expect to see in early March?
Do you really want the employee to work seven hours the last shift or not? How did you set it up? Do you know?
What would you expect to see if a project view employee is scheduled to work 8 hours starting at 11:00 PM on Saturday? Right. It's the same as above; 7 hours for the day and 39 hours for the week.
What about if the time is entered explicitly as an Hours Worked Edit? It'd be 8 hours right? Is that weird? Which is right?
Welcome to Daylight Saving Time
In most of The United States Daylight Saving Time took effect at 2:00 AM on Sunday. So, although the schedule suggests that the employee is suppose
d to work an eight-hour shift starting at 11:00 PM on Saturday, the actual, elapsed work time is only 7:00. The clock moves (at least theoretically) from 1:59 AM Standard Time to 3:00 AM Daylight (Saving) Time.
So, why are the totals paid from schedule 7:00 while those entered by hand are 8:00? This is not a bug, incidentally-it is a deliberate design decision-a feature, in fact. WTK has no way to know what the user meant by scheduling the shift from 11:00 PM to 7:00 AM for Saturday night, so it interprets this schedule literally. Because there is no hour from 2:00 through 2:59, the length of this schedule is only 7:00, and that's the amount of time that appears for that day (in purple) in the timecard editor.
When the user enters the amount 8:00 explicitly for that day in the timecard, WTK uses this amount in lieu of the scheduled amount. That is why the timecard shows this 8:00 in black rather than purple-the user has overridden the pay from schedule. Now, an amount of 8:00 entered for a project view employee is unambiguous: it means that eight hours of work is to be credited to the employee, and that (in this case) eight hours of work will be applied to that scheduled shift.
Aha, you may say! But, doesn't the timecard editor know that this is a project-view employee in the first place? When paying from the schedule, why doesn't the timecard editor simply extend the scheduled shift by one hour, to preserve the obvious intention of the scheduled shift?
Well, although this may be the obvious intention for some customers (that the employee should work an eight hour shift regardless of actual time of the out-punch), it may be obviously wrong for other customers (for example, the morning shift of workers may be scheduled to start at 7:00, which means that the nighttime shift can't stay an extra hour). Since there is no way for WTK to know what the customer wants, it takes the least invasive approach:
- The explicit time-of-day (in the schedule) is interpreted literally.
- The duration of the Hours Worked (entered in the timecard) is interpreted literally.
- Actual timecard data overrides the schedule.
Daylight Saving Troubleshooting Tips
Many customers see problems such as this on or near the date of the change to Daylight Saving Time, and they call Kronos Global Service or file troubleshooting/bug reports. And, bugs are genuinely found. Many times, however, the system is working as designed even though its design is not the one that best serves a particular customer. Here are some tips for diagnosing Daylight Saving Time troubles which might help forestall (or may help specify) a bug report.
Verify the time zone of the punches & the employee
First, remember that Daylight Saving Time troubles are basically Time Zone troubles. Employees having a time zone that does not observe Daylight Saving Time cannot possibly have DST troubles, for example. The first thing to do when/if you suspect a DST problem is to verify the following:
- The employee's Job Assignment shows the correct default time zone. Punches added through the timecard or group editor or HTML timecard will have this time zone by default-unless you edit the punch (in the time card editor) to have a different time zone. Here's a screenshot of this portion of the People Editor:
- There is a WTK Global Setting that must be set to the database server's time zone. This is configured as part of the WFC installation process, and it is important that it be correct. The timestamps (start/end times) in WFCTOTAL and the various total views are adjusted to reflect the database server time zone, as are the various time stamps that trigger background processing. Here is the location of this parameter on the System Configuration | Global Settings screen, so that you can verify it:
- Finally, remember that punches coming in from a time clock will bear a time zone. It is possible that punches collected in one location will have a different time zone from the employee's default time zone. You won't see this in the timecard editor UNLESS YOU ‘EDIT' THE PUNCH:
Verify TIMEZONE row in the database
Having determined that the punch does have the expected time zone, you should verify that the definition of Daylight Saving Time is correct for that time zone. The Workforce Central Suite does not use the Internet nor does it rely upon the Java JRE for the rules pertaining to Daylight Saving Time. Instead, there is a table in the database called TIMEZONE that defines rules for each of the Kronos time zone definitions. As of WFC 6.1 (and perhaps this has been retro-fitted to earlier versions), the data in this table is now effective-dated.
The good news is that you can change the data in this table to create your own Kronos Time Zones each with its own rules for Daylight Saving Time. The bad news is that if the data in this table is wrong it will seem as if WTK is wrong. Errors in the table as installed with WTK have been known in the past, so don't just assume that it must be right "out of the box."
Override Pay-From-Schedule for Project View Employees
If you really do encounter the situation described in this article, remember that you can always enter an explicit amount of hours in the employee's timecard, either individually or as a group edit (or through the XML API), and that any amount you enter this way will be displayed as expected.
Create special schedule or special work rule transfer for the one shift
If entering explicit hours for every affected employee is too much work or is otherwise not feasible, you may be able to create a special work rule to be used for just this one shift. Such a work rule would contain break rules, bonus/deductions, minimum-to-qualify limits, etc., that make sense for a shift that will be missing this one hour.
Remember, it is reasonable to expect some manual adjustments
Finally, please remember that the fact that manual adjustments are needed is not necessarily a bug. (This is not to say that bugs haven't been found, or that you shouldn't pursue the behavior that would seem to be consistent with what I've described here.)
Get the promised ROI out of your Kronos Implementation
Gain insights into how to get the most from what you have. Kronos Performance, Configuration Best Practices, Enforcing your Labor Policies, Custom Training needs, and Fit/Gap driven plans to help get you from 'here' to 'there' by requesting a free review.
About the author: David Goldhirsch is a senior software engineer. He worked for 15 years at Kronos Incorporated, contributing (among other things) to how Daylight Saving Time and time zones are handled within Timekeeper Central, Timekeeper Central for Windows, and Workforce Central.