Format a datetime for display in the user's timezone

ServiceNow stores all datetime values in UTC, but users expect to see times in their local timezone. The platform handles this conversion automatically through getDisplayValue() and setDisplayValue(), but most developers reach for GlideDateTime methods that operate in UTC and produce confusing results. The key insight: let the platform do the timezone conversion for you — don't try to calculate offsets manually.

When to use this

• Displaying datetime values in email notifications or catalog item summaries
• Building custom REST API responses that need user-friendly datetime strings
• Processing user input from UI pages or external integrations with datetime strings
• Generating reports where datetime fields need to show in the report viewer's timezone

When NOT to use this

• Don't use this in client scripts — the browser handles timezone conversion automatically through g_form.getDisplayValue()
• Don't use getDisplayValue() for datetime calculations — use GlideDateTime methods on the raw UTC value instead
• Don't format datetimes for system-to-system integrations — external systems expect UTC ISO strings
• Don't use this in scheduled jobs without explicitly setting a session context — jobs run as system with no user timezone

Key behaviors and gotchas

• getDisplayValue() uses the current session's timezone and locale from gs.getSession().getTimeZoneName()
• setDisplayValue() parses user input and converts it back to UTC for storage — handles ambiguous times during DST transitions
• Empty datetime fields return empty string from getDisplayValue() — null checks on getValue() prevent unnecessary processing
• GlideLocale allows custom datetime patterns like MM/dd/yyyy HH:mm that still respect timezone conversion
• Business rules and script includes inherit the session timezone from the triggering user — background jobs default to system timezone
• Date-only fields (glide_date) are not affected by timezone — they display the same value for all users