GlideDateTime and dates
Quick answer
Store, compare and display dates correctly across timezones, and calculate durations that survive daylight saving.
Key takeaways
- Values are stored in UTC and rendered per user
- Use GlideDateTime arithmetic, not string parsing
- Use a schedule when business hours matter
- GlideDuration display values are human readable, duration values are for maths
Storage versus display
Date/time fields are stored in UTC and displayed in the user timezone. Every bug in date handling starts with someone comparing a displayed string to a stored value.
Working with GlideDateTime
Use the API for arithmetic rather than parsing strings.
var start = new GlideDateTime(current.opened_at);
var end = new GlideDateTime();
var dur = GlideDateTime.subtract(start, end); // GlideDuration
gs.info(dur.getDisplayValue()); // 2 Days 4 Hours
gs.info(dur.getDurationValue());Business time
Elapsed time is rarely the answer for SLAs. Use a schedule so weekends and holidays are excluded.
- DurationCalculator applies a schedule and timezone
- Schedules live in cmn_schedule and can be reused by SLAs, on call and jobs
- Always state the timezone in report titles, it prevents a lot of arguments
Want to learn this properly?
Our live, instructor-led ServiceNow Training covers this hands-on, with real projects and a certification path.
Check your understanding
In which timezone are date/time fields stored?
- A. Instance timezone
- B. User timezone
- C. UTC
- D. Server local time
Show answer
C. UTC
Storage is UTC, display applies the user timezone.
What does GlideDateTime.subtract return?
- A. A number of seconds
- B. A GlideDuration
- C. A string
- D. A GlideDate
Show answer
B. A GlideDuration
It returns a GlideDuration you can display or convert.