Your ServiceNow instance needs a default time zone to determine how dates and times display across the platform. This guide walks you through setting the instance-wide default and understanding how user preferences interact with it.
Why instance time zones matter
Without a properly configured instance time zone, your ServiceNow data shows timestamps in UTC, which confuses end users and makes incident timelines hard to follow. This affects everyone: agents trying to understand when problems occurred, managers reviewing SLA performance, and users submitting requests who see confusing timestamps. The default instance time zone becomes the fallback for any user who hasn't set a personal time zone preference — and most users never do.
How ServiceNow handles time zones
ServiceNow stores all timestamps in UTC internally but displays them based on a hierarchy: user personal preference first, then instance default, then UTC. The instance default is controlled by the glide.sys.default.tz system property. When you change this property, existing records don't change their actual timestamps — ServiceNow just displays them differently based on the new zone. User-level preferences always override the instance setting, so power users can set their own zones while everyone else gets the sensible default.
Beyond the basic setup
Once your instance default is set, consider whether different groups of users need different time zones — customer service teams in multiple regions, for example. You can build business rules that set user time zones automatically based on location fields during user provisioning. For global instances, document your time zone strategy clearly since changing the instance default later affects how historical data appears to users.
Before you start
- •admin role
Sourdough: ServiceNow Monitoring and Analytics
A Chrome extension for ServiceNow Admins and Developers with essential tools, analytics, graphs and monitoring features.
Free to install. Pro $5/month after a 14-day no-card trial.
Pro requires the ServiceNow admin role. Upgrade inside the extension.
Step by step
Navigate to System Properties
Go to System Definition > System Properties. You'll see a long list of system properties that control instance behavior. These are key-value pairs that ServiceNow reads at runtime to determine how features work.
Find the time zone property
Filter the list by typing 'glide.sys.default.tz' in the Name field and pressing Enter. This property controls the instance-wide default time zone. If it doesn't exist yet, you'll need to create it.
Set the time zone value
Click on the property record or create a new one with Name 'glide.sys.default.tz'. In the Value field, enter the time zone identifier like 'America/New_York' or 'Europe/London'. Use the standard tz database format — don't use abbreviations like EST or PST since they don't handle daylight saving time correctly.
ServiceNow includes a time zone picker in user preferences — check there to see the exact format for your target zone.
Save and test the change
Save the system property. The change takes effect immediately — no restart required. Open an incident or other record with timestamps to verify they now display in your chosen time zone. Create a test record and confirm the timestamp appears correct.
Verify user override behavior
Log in as a test user who has a personal time zone preference set. Confirm that their personal setting still overrides the instance default. This ensures you haven't broken existing user configurations.
Best practices
Use tz database identifiers like 'America/Chicago' rather than abbreviations — they handle daylight saving time transitions automatically.
Change the instance time zone during maintenance windows since it affects how all historical timestamps display to users immediately.
Document your time zone choice clearly for future administrators — changing it later confuses users who reference historical records.
Test with users in different roles before rolling out the change since some teams may have built workarounds around UTC timestamps.
Don't assume all users want the same time zone — consider building automated user provisioning that sets personal time zones based on location data.
Test Your Knowledge
Quick 3-question quiz — see how your ServiceNow skills stack up.
A list view on a table with millions of records is slow. Best fix?
Select an answer to continue