You have may heard about the attribute called "Time zone" on your foundation data in ServiceNow already, especially on tables like [sys_user] and [cmn_location]. There are a lot of use cases, why you should have correctly populated time zone attribute on location/user data, and it's valuable to have those data in good shape. But unfortunately, there is no OOB logic in ServiceNow, which would somehow manage the population of those attributes.
One of the reasons you may need to have the correct time zone on the user's profile could be, e.g., displaying accurate timestamps in Service Portal.
In this article, we will show one of the automation ways how you can achieve to have a user's time zone automatically populated based on the user's location – so, the premise for the approach described below is that the user has properly filled in the "Location" attribute on his profile and that location has time zone.
As the user’s time zone will be inherited from the location, we must first ensure the population of the location’s time zone. For that, we could create, e.g. new custom mapping table, like in the picture below, with columns “City”, “Country”, and “Timezone”. So the location’s time zone would be taken from this custom table based on the location’s city and country combination.
But this approach is not the optimal one. The drawbacks could be:
- You need to create a new custom table
- The “mapping” data needs to be maintained
So, what else we can do?
The OOB business rule (in the picture below) called “get_lat_long” on the [cmn_location] table, which populates location’s longitude and latitude attributes may be helpful for us.
This BR uses Google API and the Google API, especially the Google Time Zone API, which we can use for the location’s time zone population as well!
The Time Zone API provides time offset data for locations on the surface of the earth. Request the time zone information for a specific latitude/longitude pair and date. The API returns the name of that time zone, the time offset from UTC, and the daylight savings offset.
A Time Zone API request takes the following form: https://maps.googleapis.com/maps/api/timezone/outputFormat?parameters
where outputFormat may be either of the following values:
- JSON or
- location (A comma separated latitude, longitude tuple)
- timestamp (The desired time in seconds since midnight, January 1, 1970 UTC. The Time Zone API uses the timestamp to determine whether or not Daylight Savings should be applied, based on the time zone of the location.)
So, what we need to do in ServiceNow to get time zone data, is somehow call the Time Zone API and, as one of the request parameters, use the combination of location’s latitude and longitude attributes populated by OOB business rule “get_lat_long”. For that, we can either use IntegrationHub or create an outbound REST message. In this case, we will create an outbound REST message which will return time zone data in JSON format.
Now let’s create two new custom business rules on [cmn_location] table.
- The first one will be triggered when location’s latitude/longitude changes and will populate the time zone based on the Google Time Zone API. E.g.
- The second one will be triggered when location’s time zone changes and will populate that time zone to all users with particular location. E.g.
Let's do a summary.
Location is created/updated, and this action will trigger the OOB business rule "get_lat_long". In addition, the change of location's latitude and longitude attributes will trigger our newly created business rule, which populates the location's time zone based on the response from Google Time Zone API and after that, the time zone will be populated for all users with a particular location.
And that's all. With this approach and the usage of Google API, we can quite simply and without some additional manual work ensure the population of the time zone attribute.
Did you enjoy reading this? Let us know your thoughts.
Senior ServiceNow Consultant