Date Variable values change when saving a record that includes the Variable Editor, if .disabled=true has been set for the variable element using DOM manipulationDescriptionIf all variables are made read-only in the Variable Editor on record forms using a DOM manipulation client script taking this form, then Data type variables will get updated by a number of hours. Due to the session timezone not being taken into account on the update once the variable has been disabled in this way, the date value will be updated with +/- the user's session timezone offset. var ve = $('variable_map').up('table');//Disable all elements within with a class of 'cat_item_option've.select('.cat_item_option', '.slushselectmtm', '.questionsetreference').each(function(elmt){ elmt.disabled = true;});Steps to Reproduce Create a Client Script, onLoad, for table Requested Item [sc_req_item], containing the following script: var ve = $('variable_map').up('table');//Disable all elements within with a class of 'cat_item_option've.select('.cat_item_option', '.slushselectmtm', '.questionsetreference').each(function(elmt){ elmt.disabled = true;}); Log in as a catalog_admin role user, or anyone able to update a RITM. Set the user's profile to a timezone several hours away from GMT. Open any existing Requested Item RITM record that has Date type variables in default view so that the Variable Editor is displayed, and update the comments of the record. Note that the date variable's value has changed by the same number of hours as the user's offset from UTC. WorkaroundThere is no workaround for this behavior as DOM manipulation is not supported within the ServiceNow platform. Unless the g_form API is used for making variables hide or read-only, this type of scripting will break the application. If this is done with unsupported direct DOM manipulation rather than the supported g_form API, our code is not aware it has been done, which negatively affects the update of the record. The side effect is that on systems that have a custom date format set or the system timezone is not GMT, date variables can be corrupted or the dates changed by several hours equal to the GMT offset. For more information, see the product documentation topics Unsupported client scripts and Client scripts good practices: Avoid DOM manipulation. Related Problem: PRB924640