Date/Time validation script

[Masa29]

We got "Invalid Text" error for date/time field of value '1970-01-01 00:00:00' GMT while saving the record on UI.

Below procedure can reproduce the issue (SN version Geneva):

A. Preparation  

1. Create a new table u_datetime_test

2. Add a field u_datetime_field

Type: Date/Time

Readonly: true

Default value:  javascript:gs.dateGenerate('1970-01-01', '00:00:00')

3. Add a client script for u_datetime_test.

Name: DateTime Test - Form on load

Type: onLoad

Table: u_datatime_test

Script:

function onLoad() {

   var datetime_val = g_form.getValue('u_datetime_field');

   if(!datetime_val){

  return;

   }

   if(datetime_val < '1970-01-01'){

  g_form.setValue('u_datetime_field', '1970-01-01 00:00:00');

   }

}

B. Test steps

1. Set SN time zone to GMT

2. Open the form of u_datetime_test table. (http://{instnace_name}/u_datetime_test.do)

3. Click Save buttone to create a new record.

4. Switch SN time zone to US/Eastern

5. http://{instnace_name}/u_datetime_test_list.do

Result: the value of u_datetime_field is '1969-12-31 19:00:00' (Date/Time display value is converted to local time zone)

6. Click on the record to open the form

Result: the value of u_datetime_field is '1970-01-01 00:00:00' (Display value is changed by the client script 'DateTime Test - Form on load')

7. Click Save button.

Result: Error message "Invalid text" under u_datetime_field and the record cannot be saved.

Extended tests :

Preconditions: Create a new record in GMT for every test case and open the record in EST - make sure the value of u_datetime_field is '1970-01-01 00:00:00' (GMT) in XML and display value is less than '1970-01-01 00:00:00' in list view.

Test case 1. If I change u_datetime_field to be writable (Readonly  = false), the record can be saved successfully, and the value of u_datetime_field is '1970-01-01 05:00:00' GMT in xml (GMT = EST + 5 hrs).

Test case 2. u_datetime_field is Readonly. Goto System Definition -> Validation Scripts -> Deactive the script for Date/Time (Type = Date/Time), then the record can be saved successfully.

Conclusion:  

1. If the display value of Date/Time field is less than '1970-01-01 00:00:00', record cannot be saved due to "Invalid text" error.

2. If the display value of Date/Time field is greater than '1970-01-01 00:00:00' and the Date/time field is readonly, record cannot be saved due to "Invalid text" error.

3. If the display value of Date/Time field is greater than '1970-01-01 00:00:00' and the Date/time field is NOT readonly, record can be saved and value of the Date/time field is converted to GMT based on the display value.

4. If the display value of Date/Time field is less than '1970-01-01 00:00:00', record cannot be saved due to "Invalid text" error no matter the field is readonly or not.

4. If the Date/Time validation script is disabled, the record can be saved successfully even though the display value is less than '1970-01-01 00:00:00'.

I find the link  http://wiki.servicenow.com/index.php?title=Validate_Date_and_Time#gsc.tab=0. Our Date/Time validation script is the one with  hard coded format. It is the original script coming with ServiceNow release.  Questions:

How does the date/time validation script work? i.e. Does it  validate datebase value or display value?

Why does the display value '1970-01-01 00:00:00' passes validation when the field is read/write but gets error when the field is readonly?

If the original validation script may cause problem, why ServiceNow doesn't use the updated script by default?

[Mwatkins]

Open up the Upgrade History record and Revert a customization

[Masa29]

Thanks Matthew for the prompt answers.

Checked the update history: didn't find a record for this script in sys_upgrade_history_log; found it in sys_update_xml. The script is included in a update set.

So I think the Date/Time validator is not included by ServiceNow release. It was added by our update set.

Thanks,

Masa

[Mwatkins]

Well the sys_id 829b0bb0533131008d7d154f811c08f7 is the out-of-box sys_id, so it is definitely the one from the out-of-box ServiceNow system. Why it didn't come up in the upgrade logs is a bit of a mystery to me. There should be a number of upgrade history log records with the "Skipped" Disposition.

In any case, since you already have sys_update_xml records tracking changes, I suppose you would be just as well suited to simply update the security script with the out-of-box code that I supplied in my earlier update. That will fix the behavior.

function validate(value) {  

      // empty fields are still valid dates    

      if(!value)    

              return true;    

      // We "should" have the global date format defined always defined. but there's always that edge case...    

      if(typeof g_user_date_time_format !== 'undefined')    

              return isDate(value, g_user_date_time_format) ? true : getMessage("Invalid Date");    

      // if we don't have that defined, we can always try guessing    

      return parseDate(value) !== null ? true : getMessage("Invalid Date");    

}    

[Masa29]

OK. sys_script_validator_829b0bb0533131008d7d154f811c08f7 is in sys_upgrade_history_log table.

Disposition = Inserted

Resolution = Not Reviewed.

But sys_id 829b0bb0533131008d7d154f811c08f7 is not found in sys_script_validator table.

In sys_update_xml, a new Date/Time validator with different sys_id is created by an update set.

[Mwatkins]

Sometime in the past someone deleted your out-of-box sys_script_validator record.

You have two options:

1) Import the out-of-box one, I've attached it to this post (this will have the same sys_id as the original one that is missing in your environment)

2) Change the content of your existing one to match the out-of-box script. (I included it in two of my previous updates)