Why do ServiceNow time fields add an hour?

[bcronrath]

Why aren't ServiceNow time fields accurate?   They seem to attempt to keep in line with timezone settings, but add an hour.   For instance, let's say I create a time field, and it's set to 00:00:00 on the form with my current timezone setting of America/LA.   I then update my timezone to Australia/Sydney, and I can see the time field update to 18:00:00 on the form.   That's fine, and leads me to believe the times are stored as a proper UTC value.   However, when I try to work these values into scripts, it is adding an hour to the value.

For instance, let's say I set it back to my local time of America/LA, and now update the field to be the current time of 11:00:00.   If I do a gs.print(time field) to get the UTC printout, it comes back as 19:00:00, when in reality it should be 18:00:00 since we are in pdt currently which should equate to 7 hours off from GMT.   Even if I do a gs.nowNoTZ I get the proper value of 18:00:00, so why are the time values not being stored properly on the back end?   If I now have to program in an extra hour offset to all my calculations, is it going to be wrong when daylight saving times rolls around and we are back to pst?   This is making it unclear how to do time based calculations with scripting.

Best regards,

Brian

[mloranc · Accepted solution]

Hi Brian,

The problem actually lies with Daylight Savings Time. Standard timezone is -08:00, while we're in DST mode then it's -07:00. The key here is don't program an extra hour offset in your calculations when setting fields because it will mess up all your activity times after we "fall back" in November. I've done some work with time-stamps in ServiceNow and found that most of the calculation happens at render when it comes to the personal settings. The data itself is always stored in UTC.   So, using a script to display the values might give you seemingly "off" results. Just make sure those don't come through on the page load of where your data is stored and there shouldn't be a problem. I hope that kind of sheds some light. If not, feel free to ask more.

[bcronrath]

I guess my issue right now is that I'm trying to program in some functionality where some users can input settings for timeframes during days at which certain automation will ping them or not, but if I'm understanding correctly I'm basically going to need to find a way to program in my own daylight savings times calculations because the time field doesn't account for it by design?

[mloranc]

You should be able to just use the standard out of box time-stamp generation, and let the system handle the daylight savings time calculations. When it displays to the value in a Date/Time field or performs an operation, it should take that DST into consideration. Here's some of the limited documentation on the GlideDateTime functionality: GlideDateTime

For development, I'd recommend not worrying about DST if all you're doing is loading up data for time fields. That data should store correctly in UTC format, and then display accurately based on the user's current timezone settings.

[bcronrath]

I think I'm not seeing that be the case though.   Try using this test in a fix script after creating a Time Field on the sys_user table:

var glU = new GlideRecord('sys_user');

glU.addQuery('sys_id',gs.getUserID());

glU.query();

while(glU.next()){

gs.print(glU.u_new_time_field);

  gs.print(gs.nowNoTZ());

}

Enter a time into the timefield that matches the current time (and make sure your user timezone is set to your current timezone) and see if the UTC printout matches.   Shouldn't it match in this case since nowNoTZ should be the current UTC timestamp?   I'm seeing u_new_time_field be 1 hour ahead of nowNoTZ