Date/Time fields in ServiceNow are stored in the database in UTC timezone. They are adjusted for the individual user’s local timezone as defined by their profile at runtime in the UI. This allows anyone viewing the data to see date/time values in their local timezone to avoid confusion. When we replicate that data we just replicate it as is in UTC, and write it to the target without doing any kind of timezone offset since there isn’t one in the context of a machine integration. Typically reporting solutions can account for this and adjust based on your end user’s needs. This is fairly standard across most enterprise applications. | UI Text Box |
|---|
| If you want to explicitly convert all data to a specific timezone for replication you can use a “Before Share Script” in bulk shares and dynamic shares to do this. We DO NOT recommend it, as it can cause issues if the reporting or viewing technology being uses then adjusts it again in their UI. You also need to consider the impact of Daylight Savings. Something converted and replicated during Standard Time, could be off by an hour compared to something converted during Daylight Savings time. |
A simple example script to do this here shows converting sys_updated_on and opened_at to US/Eastern timezone during replication. | Code Block |
|---|
// Date/Time variables you want to update
var timesToUpdate = ["opened_at", "sys_updated_on"];
var curTimeZone = "America/New_York";
// Get the specified timezone
var tz = Packages.java.util.TimeZone.getTimeZone(curTimeZone);
// Edit specified variables with the offset
var time;
var timeZoneOffset;
for(var t in timesToUpdate){
time = new GlideDateTime(current.getValue(timesToUpdate[t]));
time.setTZ(tz);
timeZoneOffset = time.getTZOffset();
time.setNumericValue(time.getNumericValue() + timeZoneOffset);
current.setValue(timesToUpdate[t], time);
} |
You would place this in the Before Share Script section for any shares where you need it, and specify those fields you want to convert. | 
