ANS-0866 · SUITESCRIPT DEVELOPMENT

How to Compare Dates Across Different Timezones in NetSuite Scripts?

Accurately compare dates across timezones in NetSuite SuiteScript, managing server defaults.

Short answer

NetSuite's server-side scripts default `new Date()` to Pacific Time (PST/PDT), and `{today}` in scheduled saved searches reflects the server's timezone. For accurate cross-timezone date comparisons, leverage SuiteScript 2.x's `N/format` module. Use `format.format()` with the `timezone` option to explicitly convert and standardize dates.

Scenario

Comparing dates across different timezones in NetSuite can lead to discrepancies. A date set by a user in Montreal (EST) might be interpreted by a server-side script as Pacific Time (PST/PDT) when using `new Date()`. This can result in incorrect comparisons, especially at day boundaries. The issue is compounded when scheduled scripts, executed by the 'SYSTEM' user, retrieve `{today}` from saved searches, as this value also defaults to the server's PST timezone.

Solution

NetSuite's server-side environment operates in Pacific Time (PST/PDT). This means that new Date() objects created within SuiteScript 2.x scripts will default to PST. Similarly, when a scheduled script, executed by the 'SYSTEM' user, retrieves the {today} token from a saved search, that value will also reflect the server's PST timezone. This inherent behavior often leads to discrepancies when comparing dates across different timezones, as a date that is already 'today' in a user's local timezone (e.g., Montreal EST) might still be 'yesterday' in the server's PST.

To accurately compare dates across timezones, the recommended approach in SuiteScript 2.x is to leverage the N/format module. This module provides robust functionality for handling date and time conversions, allowing developers to explicitly define the target timezone for formatting and parsing operations.nn

  1. Load the N/format module in your SuiteScript 2.x script:n

javascriptn/**n * @NApiVersion 2.xn * @NModuleScope SameAccountn */ndefine(['N/format'], function(format) {n    // Your script logic heren});n

n

  1. Use format.format() to convert dates to a common timezone (e.g., the user's timezone or UTC) before comparison. For example, to convert a date to Montreal's Eastern Standard Time (EST):n

javascriptnvar dateToConvert = new Date(); // This will be in PSTnvar montrealTime = format.format({n    value: dateToConvert,n    type: format.Type.DATETIME,n    timezone: format.Timezone.AMERICA_NEW_YORK // Represents EST/EDTn});n// 'montrealTime' is now a string representing the date/time in Montreal's timezone.n// You might need to parse it back to a Date object or compare as strings depending on your needs.n

n

  1. Alternatively, convert both dates to a common reference point, such as UTC, for comparison.n

javascriptnvar dateInPST = new Date(); // Example date from scriptnvar dateFromUserField = new Date('January 31, 2012 00:00:00 PST'); // Example user date, assuming it was parsed into PSTnnvar dateInUTC_PST = format.format({n    value: dateInPST,n    type: format.Type.DATETIME,n    timezone: format.Timezone.UTCn});nnvar dateInUTC_User = format.format({n    value: dateFromUserField,n    type: format.Type.DATETIME,n    timezone: format.Timezone.UTCn});nn// Now compare dateInUTC_PST and dateInUTC_User (as strings or after parsing back to Date objects)n

By consistently converting all dates to a single, known timezone using N/format before comparison, developers can ensure accuracy regardless of the server's default timezone or the user's local settings.

Expert NetSuite Support

Need help with this NetSuite issue?

SuiteScript Development consulting and configuration support

Talk to a consultant