Date variables showing wrong

kristenankeny · ‎11-17-2016

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 · ‎01-12-2017

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.

View solution in original post

tim2222 · ‎06-07-2018

Thanks for your help. We only have a system user with a date format set - all the users triggering corrupt records didn't have a date format set. Perhaps it is an issue with having a mix of users with and without date formats.

I'm currently trialling having the date format set on users and after two days haven't seen a recurrence. It'll be a few weeks before I can be confident this resolves the issue though.

As to a permanent fix, I do not expect to see data corruption regardless of how we configure the system. This should be addressed by more than a workaround.

tim2222 · ‎06-20-2018

I'm sketchy on whether our issue is related to this forum post or not but hopefully this information will assist others who may come across this ...

I've gone back over my analysis of this and found that the corruption started - to the day - when we upgraded from Helsinki to Jakarta patch 4.

I got this data by using a report:

Table: sc_item_option_mtom
Type: Time-Series Column
Group by: Parent Item > Requested Item
Trend by: Dependent Item > Updated
Per: Week
Filter: Dependent Item > Value STARTS WITH 00
Filter: Dependent Item > Value CONTAINS -
Filter: Dependent Item > Value DOES NOT CONTAIN :