Date variables showing wrong

[kristenankeny]

We have a situation with date variables, but have not yet figured out how to reproduce the issue. Occasionally, users will submit requests for items that have date variables. At some point in the process, the date will display an odd value. Users sometimes try correcting the date, which then shows that the original value was the right date value, but again new value is odd.

Here is an example of a variable's history:

Does anyone have any experience with this and any suggestions as to what might be happening? We aren't scripting anything with the date variables after the requested item is created.

[kristenankeny · Accepted solution]

After talking with ServiceNow, it sounds like there is a known bug that is difficult to replicate, but is caused by to overlapping items:

• OOB methods for date variables does not properly handle situations where a user has selected a personal date format that is different from the system format (this is especially true with date formats beginning with dd)
• The variable pool seems to be shared and another user's selected date might be stored, causing the date the current user is attempting to enter to be corrupted

Our current solution for this, though we are not positive it will resolve all issues, given that there might be a problem with regard to the variables, is to remove the ability for users to select personal date and time formats and to only use the system date and time formats.

[tim2222]

We're experiencing the same issue.

Since October 2017 about 2% of date variables are being corrupted. The date value starts out correctly - as inputted by the user - but a future save corrupts the date value. We see the same pattern in the audit history (with some variation across records):

1. First entry shows a corrupt date value (even though it looks OK on form).
2. Second entry shows the value changing from the correct value to a corrupt value.
3. Further entries shows the value alternating between corrupted values.

The corrupted values always start 00.

All our users are set to "None" for their date format. Our system date format is dd-MM-yyyy.

[kristenankeny]

After enforcing a universal date/time format, we have stopped having issues and have not looked into it further.

[tim2222]

When you say "enforcing a date format", do you mean you set the date format in every user's preferences (sys_user.date_format)? Are you enforcing it is the same as the system property?

My conversation with HI isn't very illuminating: some customers experience this issue, try setting the user's date format. As if data corruption is just something that happens and we don't need to understand why ... 😞

[kristenankeny]

The way it was explained to me was that their functions they're providing for dealing with dates doesn't handle a few of the date formats correctly. My question was why they provide the personalized format if their functions don't handle them accordingly. In the end, our solution was to set the date format in the basic configuration, run a script to remove all selected user preferences for date format on the sys_user table, and then hide the field from users so they couldn't change it back.