Compare two GlideDateTime values

GlideDateTime comparison looks deceptively simple, but the timezone handling will bite you. The before(), after(), and equals() methods convert both dates to the same timezone before comparison, but only if you construct the GlideDateTime objects correctly. Most developers create one from a database field (which is in GMT) and another using new GlideDateTime() (which uses the session timezone), then wonder why their time-based business rules fire at the wrong time.

When to use this

• Checking if a record is overdue in a Business Rule or Scheduled Job
• Determining record age for SLA calculations or data retention policies
• Validating that end dates come after start dates in forms or workflows
• Sorting or filtering operations where you need boolean comparison results

When NOT to use this

• Don't use in Client Scripts — GlideDateTime objects don't exist client-side, use GlideAjax to call server-side comparison
• Don't use when you need the duration between dates — use gs.dateDiff() or GlideDuration instead
• Don't use in GlideRecord queries — use addQuery('due_date', '<', gs.nowDateTime()) for better performance
• Don't compare dates from different timezones without explicit conversion — the results are unpredictable

Key behaviors and gotchas

• The equals() method compares down to the millisecond — sys_created_on and sys_updated_on are rarely equal even on new records
• Empty datetime fields return null when converted to GlideDateTime — always check with gs.nil() first
• The getNumericValue() method returns milliseconds since epoch — useful for arithmetic operations and sorting
• Database datetime fields are stored in GMT but getDisplayValue() returns them in the user's timezone
• Constructing GlideDateTime with new GlideDateTime() creates current time in session timezone, not GMT
• Comparison methods handle timezone conversion automatically, but both objects must be valid GlideDateTime instances