GlideDateTime.before() — ServiceNow API

gdt.before(other)→ boolean

beginnerTested on Xanadu

What It Does

The before() method performs a chronological comparison between two GlideDateTime objects. It evaluates whether the datetime represented by the calling object occurs before the datetime represented by the parameter object in time sequence.

Internally, ServiceNow converts both GlideDateTime objects to their UTC millisecond representations and performs a numeric comparison. The platform handles timezone conversions automatically, ensuring that datetimes in different timezones are compared accurately against their actual chronological positions.

The method returns true when the calling datetime is chronologically earlier than the parameter datetime, and false when they are equal or when the calling datetime is later. If either GlideDateTime object contains invalid datetime data, the comparison may return unexpected results rather than throwing an explicit error.

Edge cases include comparing datetimes with identical values (returns false), comparing dates across daylight saving time boundaries, and handling leap seconds. The method treats identical timestamps as neither before nor after each other, making it unsuitable for sorting algorithms that require stable ordering of equal elements.

Related methods in the GlideDateTime class include after() for reverse chronological comparison, equals() for exact datetime matching, and compareTo() for three-way comparison returning -1, 0, or 1.

When to Use This

Use before() when you need to determine if one datetime precedes another in business rules, scheduled jobs, or workflow conditions. Common scenarios include checking if an incident was created before a maintenance window, validating that a task's due date falls before a project deadline, or filtering records based on temporal relationships.

Use compareTo() instead when implementing sorting algorithms or when you need to distinguish between all three comparison states (before, equal, after) in a single operation. Avoid using before() with string datetime values—convert them to GlideDateTime objects first to ensure accurate timezone-aware comparison.

Common misuse patterns include attempting to pass Date objects, datetime strings, or numeric timestamps directly to the method. These will either fail silently or produce incorrect results because the method expects specifically typed GlideDateTime objects that contain timezone and formatting metadata.

Return Value

The method returns a JavaScript boolean value: true if the calling datetime occurs before the parameter datetime, or false in all other cases (equal or after). The return value is never null or undefined under normal circumstances, making it safe to use directly in conditional statements.

When the method encounters invalid input or corrupted datetime data, behavior varies by ServiceNow version and may return false by default or throw a runtime error. Always validate that both GlideDateTime objects contain valid data before comparison to ensure predictable results in production scripts.

Free Newsletter

Enjoying this? Get one deep-dive per week.

Join 1,000+ ServiceNow pros — scripts, GlideRecord patterns, Flow Designer techniques, and career moves. Free.

Platform Behavior & Side Effects

No Business Rules, ACLs, or notifications fire during datetime comparison—this is purely a computational operation
Nothing is written to the database; the method performs read-only comparison of in-memory datetime objects
Performance is fast with minimal overhead—comparable to numeric comparison after initial timezone conversion
Results are not cached; each method call performs fresh comparison calculation
Timezone conversions happen automatically using the system's configured timezone settings and user preferences
Behavior is consistent across Business Rules, Script Includes, and Scheduled Jobs—no contextual differences
Memory usage is minimal as the method operates on existing GlideDateTime objects without creating new instances

Parameters

Name	Type	Required	Description
other	GlideDateTime	Yes	The GlideDateTime object to compare against. Must be a valid GlideDateTime instance—passing null, undefined, or other data types will cause the method to fail. Both objects must contain valid datetime values for accurate comparison.

Chrome Extension

Sourdough: ServiceNow Monitoring and Analytics

A Chrome extension for ServiceNow Admins and Developers with essential tools, analytics, graphs and monitoring features.

Instance HealthGraphs & ChartsAPI HealthDeveloper ToolsQuick SearchInstance Switcher

Add to Chrome

Free to install. Pro $5/month after a 14-day no-card trial.
Pro requires the ServiceNow admin role. Upgrade inside the extension.

Overview

Tasks

CMDB

API

Metrics

Monitor

Internals

Instance:sourdoughdev·Version:Yokohama

Instance StateONLINE

System StatusFully Operational

Session Timeout90 minutes

Logged-In Sessions2 (20 active)

Build Nameyokohama-12-18-2024_p1

IP Address10.159.128.43

Instance HealthHealth Score: 90%

🔥 5dSourdough (Chrome Plugin)Dark Mode

Code Examples

Basic datetime comparison in business rulebasic

// Business rule on incident table - before insert/update
(function executeRule(current, previous) {
    
    var now = new GlideDateTime();
    var incidentCreated = new GlideDateTime(current.sys_created_on);
    var dueDateGDT = new GlideDateTime(current.due_date);
    
    // Check if incident was created before its due date
    if (incidentCreated.before(dueDateGDT)) {
        gs.info('Incident ' + current.number + ' created before due date');
    }
    
    // Check if due date is in the past
    if (dueDateGDT.before(now)) {
        current.state = 6; // Set to resolved if past due
        gs.addInfoMessage('Incident automatically resolved - past due date');
    }
    
})(current, previous);

This example shows typical business rule usage for validating temporal relationships between incident creation time, due dates, and current time. The method provides clean, readable datetime comparisons without manual timezone handling.

Filtering records by date range in script includeintermediate

var DateRangeUtils = Class.create();
DateRangeUtils.prototype = {
    
    getIncidentsBeforeDate: function(cutoffDate) {
        var results = [];
        var cutoffGDT = new GlideDateTime(cutoffDate);
        
        var inc = new GlideRecord('incident');
        inc.query();
        
        while (inc.next()) {
            var incidentDate = new GlideDateTime(inc.sys_created_on);
            
            // Only include incidents created before cutoff
            if (incidentDate.before(cutoffGDT)) {
                results.push({
                    number: inc.number.toString(),
                    created: incidentDate.getDisplayValue()
                });
            }
        }
        return results;
    },
    
    type: 'DateRangeUtils'
};

This pattern demonstrates filtering database records using datetime comparison within a reusable Script Include. The method enables clean chronological filtering without complex encoded query conditions.

The classic mistake - comparing mixed data typesadvanced

// WRONG - This will fail or give unexpected results
var gdt = new GlideDateTime('2024-01-15 10:00:00');
var dateString = '2024-01-14 09:00:00';
var result = gdt.before(dateString); // Fails - expects GlideDateTime

// WRONG - JavaScript Date object won't work
var jsDate = new Date();
var result2 = gdt.before(jsDate); // Fails - expects GlideDateTime

// RIGHT - Always use GlideDateTime objects
var gdt1 = new GlideDateTime('2024-01-15 10:00:00');
var gdt2 = new GlideDateTime('2024-01-14 09:00:00');
var correctResult = gdt1.before(gdt2); // false - Jan 15 is after Jan 14

// RIGHT - Convert strings first
var dateString = '2024-01-14 09:00:00';
var gdt3 = new GlideDateTime(dateString);
var properComparison = gdt1.before(gdt3); // false

The most common error is passing non-GlideDateTime objects to the method. Always ensure both operands are proper GlideDateTime instances to avoid runtime failures and incorrect comparisons.

Gotchas

The method returns false for identical timestamps—use equals() to test for exact datetime matches instead of assuming before() handles equality.

Passing null or undefined as the parameter causes runtime errors rather than returning a default boolean value—always validate input parameters.

String datetime values passed directly to the method fail silently in some ServiceNow versions but throw errors in others—convert strings to GlideDateTime first.

Timezone differences between the calling and parameter objects are automatically normalized, but this can produce unexpected results if you expect literal string comparison.

The method cannot compare GlideDateTime objects with GlideDate objects—both operands must be the same GlideDateTime type for accurate comparison.

Test Your Knowledge

Quick 3-question quiz — see how your ServiceNow skills stack up.

Question 1 of 3Performance

A list view on a table with millions of records is slow. Best fix?

Select an answer to continue