Unable to change date format on field mapping since Rome

Max Nowak · ‎02-22-2022

Hi,

On both my dev instance and the customer's instance, which are on Rome, I am unable to change the date format for a field mapping. The date format always resets to "yyyy-MM-dd HH:mm:ss", no matter what I enter, and I can see that this is done by the client script "Hide Date Format":

This client script should set the visibility of the "Date Format" field to true and set "yyyy-MM-dd HH:mm:ss" as a default value if the field "Target Field" changes, meaning it's an onChange client script with "target_field" as trigger field. The thing is, I don't get why the client script is triggering, I'm not changing the value in target_field, just the date format.

This leaves me unable to accept different date formats in imports. I mean, I could potentially use a source script and handle the issue there, but it seems to me that this is a bug introduced in rome.

Am I missing something here? Is this the same for you, or do I just have two broken instances?

Max Nowak · ‎03-25-2022

A quick update with an answer that worked for me:

This seems to be a display issue. If I enter a different date format, for example "dd-MM-yyyy HH:mm", it will save this date format (verifyable in the XML), but it will always display the default "yyyy-MM-dd HH:mm:ss". If I click "save" on the record, it will actually save the default format "yyyy-MM-dd HH:mm:ss".

So, if anyone else has this problem, a workaround is to change the date format, save it, and never touch the record again. You should be able to verify via Show XML that the date format has changed, even though it might still display the default format.

View solution in original post

HarI98 · ‎09-06-2022

This...this has been busting my back for days now...really ServiceNow?

Thanks Max, just updated through list view.

Max Nowak · ‎09-22-2022

Trust me, I lost a few hours on this as well. Glad I could help!

stacey_rochelea · ‎06-22-2022

Just a note that the reason the client script is running even without a change to target_field, it doesn't ignore the onload so it runs every time that form is loaded as well. This is why you're seeing it happen even when you haven't changed a field. And as others noted, why it's changing and not saved to that value. I agree this is something new we are seeing in Rome as well.