Zhen Zhu, Senior Developer at Proven Optics, shares some of her ServiceNow tips:
One of the biggest frustrations on the ServiceNow platform (or any application) is working with the coding of dates/times. Here are the mix of scenarios we might face during a ServiceNow implementation:
- Client instance time zone is set up using location
- Client instance time zone is set up using a specific time zone
- Client instance time is set up “x” hours forward or backward
And finally, to add more confusion, according to the ServiceNow documentation:
- All times are stored in Coordinated Universal Time (UTC) and appear globally based on the system time zone. However, times appear to users in their local time zone, according to their user preference settings.
Did I also mention Daylight Savings?
You might be scratching your head and be thinking, what does this all mean? How am I impacted? Well, if you are the end user, you might not notice anything. But for a developer, this creates a headache-inducing conundrum where all financial data and consumption data have time stamps.
For example, you might be loading data with the time stamp 2020-06-01 and the system might be mapping this date to the fiscal period: May 2020. Other times, you might be in the same instance but on another table where the date is 2020-06-01 and the system will map this date correctly to the fiscal period: June 2020. Also, depending on whether the field type is Date vs. Date/Time has an impact on the result as well.
You might be thinking, why not ask all data owners to switch to a date where it is always the second of the month? Well, by the time you convince every person in the organization to start adjusting their data to a specific date criteria, you might run out of time on your own project plan. And don’t forget, you will run into the same issue with the 30th of the month, 31st of the month and also those leap years!
So before you go and give up on this problem or solve it by scenario, here is a tip!
You can use the function: .getLocalTime(); and .getTZOffset(); in your GlideDateTime record to find a) the client’s local time and then offset it to match the system time. Since all GlideDateTime queries are based on system time, this would be a universal solution to coding all and any date field.
For example, see the below coding snippet:
var date = new GlideDateTime(current.posting_date);
date.getLocalTime();
var offset = date.getTZOffset()/-1000;
date.addSeconds(offset);
var dateValue = date.getValue();
In this code, we leveraged it on a record with a posting date that was 2020-06-01, but the system was reading it as 2020-05-31. By offsetting the date based on my local time with the time zone, we were able to help the system read the date as 2020-06-01. This solution can be applied in a multitude of use-cases! Drop a comment below if you have a question or if you use this solution!
