ServiceNow: Date and Time validation on layouts and custom forms

Date and time format, along with the system timezone setting for a ServiceNow instance, can be checked under System Properties > System.

Date and Time Format Strings

Date format uses the same format strings as Java's java.text.SimpleDateFormat class, with minor exceptions. Note that MM is months, while mm is minutes — a distinction that trips people up constantly.

Field	Full Form	Short Form
Year	yyyy (4 digits)	yy (2 digits), y (2 or 4 digits)
Month	MMM (name or abbreviation)	MM (2 digits), M (1 or 2 digits)
Day of Month	dd (2 digits)	d (1 or 2 digits)
Hour (1–12)	hh (2 digits)	h (1 or 2 digits)
Hour (0–23)	HH (2 digits)	H (1 or 2 digits)
Minute	mm (2 digits)	m (1 or 2 digits)
Second	ss (2 digits)	s (1 or 2 digits)
AM/PM	a	—

Example: HH:mm:ss

System timezone is used as the default for calendars and for users who haven't set their own. Olson/zoneinfo timezone values are accepted — for example Africa/Johannesburg, America/Toronto, Asia/Tokyo, Australia/Sydney, Europe/London, US/Eastern, or UTC.

Why Validation Matters Here Specifically

Appropriate validation on required date and time fields matters more than it might seem, because different users on the same instance can be working in different timezones with different personal date/time format settings. A validation script tied to the system default format, or hardcoded to one specific format string, can end up rejecting a date that's perfectly valid for the user who entered it — just not in the format the script assumed everyone uses.

Field-Level Validation Scripts

To restrict what gets accepted on a Date-type field so it conforms with the expected format, a Validation Script can be attached to that field type:

function validate(value) {
    if (!value) {
        return true;
    }
    return (getDateFromFormat(value, 'yyyy-MM-dd') != 0);
}

Client Scripts for Date/Time Fields

The same getDateFromFormat() function is commonly used in onChange and onSubmit client scripts:

function onChange(control, oldValue, newValue, isLoading) {
    if (isLoading || newValue == oldValue) {
        return;
    }
    if (getDateFromFormat(newValue, g_user_date_time_format) == 0) {
        g_form.showFieldMsg('yourField', 'Invalid date', 'error');
    }
}

function onSubmit() {
    if (getDateFromFormat(g_form.getValue('yourField'), g_user_date_time_format) == 0) {
        g_form.showFieldMsg('yourField', 'Invalid date', 'error');
        return false; // Stop the form submit event
    }
}

Use g_user_date_time_format (or g_user_date_format for date-only fields) rather than a hardcoded format string like 'yyyy-MM-dd HH:mm:ss'. These are built-in global variables that reflect the current logged-in user's actual date/time format preference — which can be different from the system default and different from another user's preference on the same instance. Validating against a hardcoded format works only by coincidence, when the user's personal setting happens to match it; validating against g_user_date_time_format works correctly regardless of what format that specific user has configured.

Important: This Doesn't Work Everywhere

getDateFromFormat(), g_user_date_format, and g_user_date_time_format are Core UI (classic platform UI) constructs only. They are not available in:

• Agent Workspace
• Service Portal
• Mobile (Now Mobile / Mobile Agent)

If you reuse this exact pattern in a Workspace form or a Portal widget, it fails silently with getDateFromFormat is not defined in the browser console — not a helpful error for whoever inherits that code later. This is a real, documented platform gap, not an edge case, and it's worth flagging explicitly for anyone extending this pattern beyond classic UI forms.

For Workspace or Portal, the reliable approach is a GlideAjax call to a Script Include that performs the actual validation server-side using GlideDateTime, which doesn't have this UI-context restriction. This is the same pattern described below for custom UI pages — the difference is that for Workspace and Portal, it isn't an alternative approach, it's the only approach, since the client-side globals simply don't exist there.

Checking the Instance's Date/Time Format via Script

The date and time format settings can also be checked server-side, by querying the relevant system properties:

var rec = new GlideRecord('sys_properties');
rec.addQuery('name', 'glide.sys.date_format');
rec.query();
if (rec.next()) {
    var dateFormat = rec.value;
    gs.print(dateFormat);
}

var rec2 = new GlideRecord('sys_properties');
rec2.addQuery('name', 'glide.sys.time_format');
rec2.query();
if (rec2.next()) {
    var timeFormat = rec2.value;
    gs.print(timeFormat);
}

Custom Form Validation (UI Pages, Workspace, Portal)

For custom form validation outside classic UI forms — a UI page, a Workspace component, or a Portal widget — write a Script Include with the validation logic (mirroring the client-script logic above, but using GlideDateTime server-side instead of getDateFromFormat), and call it via GlideAjax from the client-side script. This keeps the validation logic consistent across classic UI, Workspace, and Portal, rather than maintaining two different validation implementations that can drift out of sync with each other.