How to Avoid the NetIQ User App Date Picker “Gotcha”

Oftentimes there are requirements to pick dates for workflow requests within NetIQ User Application workflows. These could be for start dates, end dates, effective dates or any other dates of interest. The possibilities are numerous for all of the situations and scenarios that might call for a user to select one or more dates during the request/approval process.

In many cases developers can just slap a text field or two on the forms and just let users enter a date value and hope that it is a correct format. Sure, developers can do extensive scripting logic to validate and even format values as users manually enter the values but let’s face it, if I want a date of October 2, 2015 it can be entered as “10/02/2015” or “02/10/2015”. Depending on the format the user is accustomed to it can be Month/Date/Year or Date/Month/Year format and scripting would usually find this to be a valid date in either format but would result in a date of October 2, 2015 or February 10, 2015. One is correct and the other is WAY different than the user desired with no way to know that the system expected a different format. Sure, you can add text to the screen to list the expected format but let’s face it, users don’t always read things like that and data entry is a common issue.

NetIQ gives us a date picker field to avoid this pitfall. The field allows users to select the desired date from a calendar pop-up control (yes, pop-up blockers can be an issue making this work) that then populates the field with the desired date in the expected format. The control can be configured to show different values for the days of the week as well as the months. So you could have simple abbreviations for days such as “S, M, T, W, Th, F, Sa” or full names if you like. And the same thing for the months.

The gotcha with this control is how it handles dates though. Let’s say that you pick today’s date in the control from your browser that is set to your local timezone. The date picker field shows the date you selected which is all fine and good. However, when the form is submitted the date you selected is converted and stored as a date based on the UTC timezone, regardless of your local timezone. This means that depending on the difference between your local timezone and the UTC timezone the date could be changed from the date selected to date before or the date after. So far example, if I picked October 2, 2015 in my local timezone of CST the workflow would actually record the date as October 1, 2015 because the time difference between CST and UTC. The timezone conversion happens automatically and is not an option in the control properties. This is so the date value can be universal and is not dependent on any timezone. This makes it easier to display and convert in future operations without needing to know the timezone that the original value came from. Its a nice feature for sure but in situations where users are selecting specific days for specific events or tasks it can be quiet a pain because it means a person’s rights or access could be granted or taken away prematurely which is a big security no-no. Conversely, it also means that a person’s rights or access could be given for a longer period of time than desired which is a bigger security no-no.

The real problem with this scenario is that the end-user selecting the date doesn’t know this translation happens and that the date selected is not the date recorded. The request form shows the selected date and the conversion happens when the form is submitted so the end-user thinks the date they selected is the date submitted. This can obviously cause some confusion if the request goes to an approver who is looking for one date and sees one that is slightly different. It could cause requests to be denied which could confuse the requestor because the date submitted was correct but the date that appears in the approval is wrong. Obviously this would cause some issues that would bubble up to developers of the workflows which is not easy to track down if you don’t know what happens behind the scenes for these controls.

So how do you get around this gotcha?

For most developers the solution would be exactly what I mentioned up front; slap a text field on the form and let the users enter the desired dates manually. Sure, that would do it but you have the risks I mentioned along with the extra work of having to create the validation scripts.

There is an easier way!

If you look at the properties of the date picker control you will find a property called “Datetime indicator”. By default this value is set to false. With this value set to false the user only selects a date, however, when this property is set to true it also requires the user to choose a time. When users pick a time it forces the date and time values to be recorded as entered and the UTC conversion doesn’t take place.