ServiceNow Not Setting Correct Time on a Record Created by Scheduled Job

jmiskey
Kilo Sage

What does ServiceNow have such a hard time with date/times?

 

If I run the following code in a background script, it correctly returns the date/time that is three days in the future at 5:00 AM (as shown below):

var dt = new GlideDate();
dt.addDays(3);

//set time to be 5:00 AM
var dt2 = new GlideDateTime();
dt2.setValue(dt.getValue() + ' 05:00:00');

gs.print(dt2);

 

Results:

jmiskey_0-1676638168605.png

 

However, if I place that EXACT same code in a Scheduled Job to request a clone, like this:

//Creates weekly clone of DEV2 environment.
//Runs in Friday to create Clone for following Monday morning

//go exactly 3 days in the future from current date
var dt = new GlideDate();
dt.addDays(3);

//set time to be 5:00 AM
var dt2 = new GlideDateTime();
dt2.setValue(dt.getValue() + ' 05:00:00');

var gr=new GlideRecord("clone_instance");
gr.initialize();
gr.target_instance="67b20ec61b602d10a4ed993f034bcb44"; //DEV2 instance
gr.profile="ee751137db74e510c5201c791396192e"; //System Profile
gr.scheduled=dt2; //so that it runs on Monday morning
gr.email="xyz@xyz.com";
gr.insert();

 

It sets it to 12:00 AM instead of 5:00 AM, as shown here in the Clone that was created by this Scheduled Job today:

jmiskey_1-1676638317474.png

 

I noticed that on the Scheduled Job, it gives you this message:

jmiskey_2-1676638637978.png

I tried two times, once using my specific time zone ("US/Eastern") and one using the "Use System Time Zone" setting, and it made no difference.  Both returned a time of 12:00 AM on the clone.

 

Why does ServiceNow have such a hard time with times?

Does anyone know why this would happen and how to fix it?

 

 

 

 

7 REPLIES 7

I am officially utterly confused!  These time zones have my head spinning!

 

If we manually create a clone record to go off at 5:00 AM, it goes off at 5:00 AM in our time zone (Eastern/US).

 

If I check out our current System Properties, it shows "US/Eastern" as our System timezone.

jmiskey_0-1676660746305.png

 

Then, in the Scheduled Job, I ran various tests, one with this setting:

jmiskey_1-1676660847879.png

and one with this setting:

jmiskey_2-1676660885795.png

 

In BOTH cases, when I used the Script in my original post, it returned this in the clone record it created:

jmiskey_4-1676661070832.png

 

 

The clone record I set up manually (that ran perfectly last week) looks like this:

jmiskey_5-1676661123815.png

 

Since that last one successfully and accurately ran at 5:00 AM our time last week, I am inclined to believe that the new ones created that say 12:00 AM would run at 12:00 our time.

Swamy Malluri
Tera Guru

Hi @jmiskey ,

 

Yes, the new clone request showing clone time as 12 am will run at 12 am in your.

 

You can creating clone request using workaround. add time difference between UTC and your time zone to your desired time. 

 

Example if you want to set time as 5 am, and different between UTC and your timezone is 5 hours, then in your script you can give 10 hours. as shown in below script

 

//go exactly 3 days in the future from current date
var dt = new GlideDate();
dt.addDays(3);

//set time to be 5:00 AM, need to give 10 hours
var dt2 = new GlideDateTime();
dt2.setValue(dt.getValue() + ' 10:00:00');

var gr=new GlideRecord("clone_instance");
gr.initialize();
gr.target_instance="67b20ec61b602d10a4ed993f034bcb44"; //DEV2 instance
gr.profile="ee751137db74e510c5201c791396192e"; //System Profile
gr.scheduled=dt2; //so that it runs on Monday morning
gr.email="xyz@xyz.com";
gr.insert();

 

 

If I could help you with your Query then, please hit the Thumb Icon and mark as Correct !!

Thank you

Thanks for the reply.

 

So what then does the "Time zone" field on the Scheduled Job do?  Seems like it really serves no purpose and doesn't impact anything.

 

The issue with working from UTC and just adding 10 hours is that our area has daylight savings time (DST), meaning for 6 months of the year, it would be off one hour.  That is why we were hoping to work from System time.  It still seems that using my hack may be the best bet here to make sure it always gets scheduled for 5:00 AM, regardless of whether we are in DST or not.