ServiceNow's date arithmetic is deceptively tricky because GlideDateTime objects store timezone-aware timestamps while most developers think in calendar days. The naive approach of subtracting getNumericValue() results can give you 0 days when you expect 1 because you're working with millisecond precision across timezone boundaries. GlideDuration.subtract() handles the timezone math correctly and returns a duration object that converts cleanly to whole days.
When to use this
- When calculating SLA elapsed time in business rules or scheduled jobs
- When building aging reports that need accurate day counts across date ranges
- When processing incident or change records that span multiple timezone changes
- When you need both calendar days and business days for the same date pairs
When NOT to use this
- Don't use this in client scripts — use
GlideAjaxto call server-side date calculation - Don't use this for same-day time differences — use
GlideDurationmethods for hours and minutes - Don't use this in loops over thousands of records — pre-calculate and store the values
- Don't use manual millisecond arithmetic — it fails across daylight saving boundaries
Key behaviors and gotchas
getDurationValue()returns milliseconds — always divide by 86,400,000 for daysMath.floor()prevents 0.99 days from rounding up to 1 day- Business day calculation requires a valid schedule sys_id — invalid schedules return 0
GlideDuration.subtract()parameter order matters — end date first, start date second- Negative durations occur when start date is after end date — handle explicitly or use
Math.abs() - Invalid date strings pass the truthy check but fail
isValid()— always validate before arithmetic
Never subtract getNumericValue() directly for date differences — it fails across daylight saving transitions and gives inconsistent results between UTC and local timezone calculations.
Enjoying this? Get one deep-dive per week.
Join 1,000+ ServiceNow pros — scripts, GlideRecord patterns, Flow Designer techniques, and career moves. Free.