Handling timezone-sensitive external data in ServiceNow integrations
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
- last edited
3 weeks ago
by
kh-christelle
Hello everyone,
I'm working on an integration that collects date- and time-sensitive information from external web applications and stores it in ServiceNow.
One challenge I've encountered is ensuring that user-entered dates and times remain consistent when data passes between different systems, timezones, and locale settings.
During testing, I used several external web applications because the output depends heavily on precise date, time, and location inputs. Small differences in timezone conversion can produce noticeably different results.
I'm trying to determine the most reliable approach for:
- Preserving the original user-entered datetime value
- Handling timezone conversions between systems
- Preventing daylight-saving adjustments from altering stored values
- Displaying localized times while maintaining source accuracy
For those who have built ServiceNow integrations involving external date-sensitive applications:
- Do you normalize everything to UTC before processing?
- How do you handle user locale versus system timezone?
- Are there any ServiceNow datetime pitfalls I should be aware of?
I'd appreciate any recommendations or best practices from those who have implemented similar integrations.
Thank you.
[Mod Edit - External links are not allowed on the public forum]
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
hi @ShianA
Any data coming to ServiceNow must be strictly normalized to UTC.
When setting up your inbound REST APIs or webhooks, make sure they require ISO 8601 formatted strings that explicitly indicate UTC. For storing that data, always stick to GlideDateTime.setValue() since it natively expects a standard UTC string.
Whatever you do, don't use setDisplayValue() in integration scripts like transform maps or scripted APIs. That method processes the string based on the timezone of the integration user account running the transaction. If another admin accidentally updates the timezone on that service account, your date logic will instantly break across the entire integration.
Also, never rely on the base system timezone of the instance for your logic. It creates really fragile code if system properties ever change or the instance gets migrated. Because the integration account running your scripts has its own timezone profile, it can easily skew your data if you aren't careful about which API methods you decide to use.
Happy to help! If this resolved your issue, kindly mark it as the correct answer ✅ and Helpful and close the thread 🔒 so others can benefit too.
Warm Regards,
Deepak Sharma
Community Rising Star 2025
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Hi,
As stated, getValue and setValue on GDT utilized UTC (+0) where getDisplayValue / setDisplayValue uses the users local date/time.
By using getValue you will consistantly work with UTC time no matter the users local timezone.
Just stick to UTC because its consistant
The format of the received data is not that important as setValueUTC takes 2 parameters (date/time, format)
Search google for Java simpledataformat and you can see all the different possibilities to format date time.
ex:
Date and Time Pattern Result
| "yyyy.MM.dd G 'at' HH:mm:ss z" | 2001.07.04 AD at 12:08:56 PDT |
| "EEE, MMM d, ''yy" | Wed, Jul 4, '01 |
| "h:mm a" | 12:08 PM |
| "hh 'o''clock' a, zzzz" | 12 o'clock PM, Pacific Daylight Time |
| "K:mm a, z" | 0:08 PM, PDT |
| "yyyyy.MMMMM.dd GGG hh:mm aaa" | 02001.July.04 AD 12:08 PM |
| "EEE, d MMM yyyy HH:mm:ss Z" | Wed, 4 Jul 2001 12:08:56 -0700 |
| "yyMMddHHmmssZ" | 010704120856-0700 |
| "yyyy-MM-dd'T'HH:mm:ss.SSSZ" | 2001-07-04T12:08:56.235-0700 |
| "yyyy-MM-dd'T'HH:mm:ss.SSSXXX" | 2001-07-04T12:08:56.235-07:00 |
| "YYYY-'W'ww-u" | 2001-W27-3 |
