Subtract 4 or 5 hours

[Steven Young]

Hey folks,

I need some help if you can spare me a few minutes.

I'm doing an import of Servers and we are trying to acquire the "Last Boot" time, which is being monitored.

I have a regular "String" field in SN.

and i'm trying to import a date.   I'm having an issue because SN keeps detecting it as a date/time and transforming it to GMT.

I have tried getting the value of the field,and doing a toString(), putting it in the string field.   No worky.

and date/time fields are still very confusing to me the way scripts need to be run in order to get the accurate time for you timezone, because of the date/time always being in GMT.

Can anyone help me with a script for my Timezone and to account for Daylight Savings Time?

The import field looks like so:  

9/9/2009   12:00:00 PM

4/10/2015   11:59:00 AM

1/12/2016   8:16:00 PM

1/14/2016   5:40:00 PM

the import transforms it to:

4/1/2014   1:12:00 AM                 >>>>>>>>>>>             2014-04-01 05:12:00

var boot = source.u_last_boot;
target.u_last_boot = boot;

I have looked at the wiki but dont understand how to write a script that looks at current timezone, accounts for daylight savings time, and give me my localtimezone value.

But more importantly, i dont understand why SN has to turn a string going to a string, into a date/time value?

I'm currently in Eastern US time zone.

My system time is Eastern US time zone.

[Steven Young]

Thanks Abhinay,

will this auto change the time when Daylight Savings Time ends?

Currently the hour difference from GMT   to EST is 4 hours.       after DST ends, it will be a 5 hour difference.

[Steve McCarty · Accepted solution]

Steven,

The behavior you are describing sounds to me like the import set data table is set up as a date/time field.   When you create a new data source for your import set, ServiceNow looks at the data you are importing and tries to identify the data type.   If you look at the Data Source for this import set it lists the Import Set Table name.   Look up that table in the Tables & Columns list and see if the last boot field is set to a date/time.   If that is set to a date/time, then you will need to change it to a string value.

My question to you is, why don't you want it as a date/time value?   It is much easier to sort or run reports on date/time information that is actually stored as a date/time value.   If the field you are putting the data in was a date/time field, you shouldn't have to do anything with your values.   ServiceNow is already converting your import information to GMT time, which is how it stores date/time values and if that is put into a date/time field, it will automatically convert that to your local time zone when it is displayed.

-Steve

[Steven Young]

Hey Stephen,  

Thanks for the response.   Yes, you are correct in that the import set field is set to the date/time.

The idea is that if we just use string values, no other scripting is necessary for calculating GMT vs. EST.

We are in Eastern Standard time.   and when we import these values,   there is a 4 hour difference right now, and will be 5 hours after DST ends.

Since the monitoring tool already gets the ACTUAL last boot time of the server, there is no need to do anything with the data

But as is, just doing an import, and the 4 hour difference, now it requires an elaborate script to determine actual time vs. GMT value that is imported.

We dont need this field for "reporting".     We need this field for accountability when an analyst reboots a server without a change request in.   or when updates are applied and we need to verify that it rebooted, (without going to the actual server)  

So for that reason, i was trying to get away easy without having to script a time zone and TZ with DST.

[Steve McCarty]

Since it is converting your time to GMT correctly during the import, you shouldn't need to do any scripting to save that as a date/time value.   ALL times in ServiceNow are actually stored in GMT time.   When a time is displayed it is converted to the user's time zone.   When doing scripts you can often use .getDisplayValue() or .setDisplayValue() on date/time fields to get or set the value in the current time zone.   If you use .getValue() or .setValue() on a date/time field you will get it in GMT time.  

Since you are going to want to compare the last boot to other date/time values, it would probably be best if you convert your Last Boot field to a date/time field and see if the system handles the times appropriately.   It will make it much easier down the road.   It can be a real pain to try to compare date/time values that are saved as strings.   That's just my two cents.

-Steve

[Steven Young]

Hey Stephen,

Again, thanks for the reply.

After you told me about the import field being date/time, i did convert the string on the target table to a date/time.

I know all dates are stored in GMT, and displayed in timezone.  

that is why i hate it so much.

trying to script with timezones is a pain for me.  

So here is the verdict.  

1.   My problem in trying to simplify things and just use a "string" field is what caused the import issues.

Since my source   excel field contained a date time field,   and servicenow saw that field as date time, it turned the import field into date time, which in turn (like you said) stores the current date/time in GMT.

2.   Since my import field was date/time and my destination field was "string"   i was getting the value of the field which was the GMT value.   Which is why i had to hard code the -4 hours part of the script.

As Stephen suggested, i turned the "string" into a date/time field and that corrected the issue.

The other resolution that worked was turning the import set field into a string, that way it was a string value all the way across.

I did decide to make everything Date Time   and remove the -4 hour part of the script. because SN detected it and automatically looked at my timezone and GMT and made the difference on import.

my script ended up being:

	var boot = source.u_last_boot;
	var boottime = new GlideDateTime(boot);
	target.u_last_boot = boottime;

will have to monitor after DST ends.