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 supposed 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 time card editor.

When the user enters the amount 8:00 explicitly for that day in the time card, WTK uses this amount in lieu of the scheduled amount. That is why the time card 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 time card editor know that this is a project-view employee in the first place? When paying from the schedule, why doesn't the time card 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 time card) is interpreted literally.

• Actual time card 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 time card or group editor or HTML time card 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 time card 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.

WFC Admins: Ready to Upskill?

Are knowledge gaps in WFC slowing you down? Too few Admins servicing too many employees? Frustrated waiting for service desk solutions? Take back your power by amping your knowledge.

Register for Improv's foundations course, Navigating UKG Workforce Central, an intro set of four online classes designed for the way you actually work.

Enrollment is now open!!

Click below to get started on your learning path.