Date functions — Marketing Cloud SSJS reference | Cleon

Dates in SSJS come from three sources: the global Now() helper, the native JavaScript Date constructor, and the SSJS-specific DateAdd / DateDiff / DatePart functions. The traps are familiar from the SQL surface — Now() is UTC regardless of your tenant's local timezone, month-count arithmetic is unstable around boundaries, and you have to know the cryptic date-part code strings ("y", "m", "d", "h", "n", "s") the way you'd know DATEPART(year, ...) in SQL.

Official syntax

The SSJS-native helpers (no Platform.Function. prefix needed):

Platform.Load("Core", "1.1.5");

// Current timestamp — UTC, NOT your tenant's local time
var now = Now();
// → Date object representing the current moment in UTC

// Native JS Date constructor (also UTC-based by default)
var specific = new Date("2026-05-08T14:23:11Z");
var fromMs = new Date(1746724991000);
var pieces = new Date(2026, 4, 8, 14, 23, 11);   // year, monthIndex (0-based!), day, h, m, s

// === SSJS-specific date math ===

// DateAdd(start, interval, datePart)
DateAdd(Now(), -90, "d");           // 90 days ago
DateAdd(Now(), 12, "h");            // 12 hours from now
DateAdd(Now(), -3, "m");            // 3 months ago — unstable around boundaries

// DateDiff(start, end, datePart)
DateDiff(Now(), DateAdd(Now(), 90, "d"), "d");   // → 90
DateDiff(lastPurchase, Now(), "d");              // days since last purchase

// DatePart(date, datePart) — returns integer
DatePart(Now(), "y");               // → 2026
DatePart(Now(), "m");               // → 5  (NOT 0-based; this is the calendar month)
DatePart(Now(), "d");               // → 8
DatePart(Now(), "h");               // → 14 (UTC hour)
DatePart(Now(), "n");               // → 23 (minute — NOT "m"!)
DatePart(Now(), "s");               // → 11

// === FormatDate (covered in String functions, repeated for context) ===
Platform.Function.FormatDate(Now(), "yyyy-MM-dd HH:mm:ss", "en-US");
// → "2026-05-08 14:23:11"

// === Native JS Date methods ===
var d = Now();
d.getFullYear();                    // → 2026
d.getMonth();                       // → 4   (0-indexed; January = 0)
d.getDate();                        // → 8   (day of month)
d.getDay();                         // → 4   (day of week, 0 = Sunday)
d.getHours();                       // → 14  (UTC hour)
d.getMinutes();                     // → 23
d.getTime();                        // → 1746724991000 (ms since epoch)
d.toISOString();                    // → "2026-05-08T14:23:11.000Z"

The datePart string codes (used by DateAdd / DateDiff / DatePart):

| Code | Means | |---|---| | "y" | Year | | "m" | Month | | "d" | Day | | "h" | Hour | | "n" | Minute (not "m" — that's month) | | "s" | Second | | "q" | Quarter | | "w" | Week |

| Function | Returns | Notes | |---|---|---| | Now() | Date object | Current UTC moment | | DateAdd(date, n, part) | Date | Add n of part to date | | DateDiff(start, end, part) | Integer | Difference in whole units of part | | DatePart(date, part) | Integer | Extract calendar part from date | | new Date() | Date | Current moment (same as Now() in practice) | | new Date(year, mon, day, ...) | Date | Constructor with 0-indexed month | | new Date(isoString) | Date | Parsed from ISO 8601 string | | new Date(ms) | Date | From milliseconds since epoch | | Platform.Function.FormatDate(d, fmt, loc) | String | Locale-aware formatting | | Platform.Function.SystemDateToLocalDate(d) | Date | UTC → local based on tenant timezone setting |

Reference:

What survives in production

`Now()` is UTC, not your tenant's local time

Same trap as SQL's GETDATE(). SSJS scripts that do "send between 9am and 6pm Buenos Aires time" using raw Now() will fire at the wrong local hours.

// AT RISK — checks UTC hour, fires at wrong local time
var hour = DatePart(Now(), "h");
if (hour >= 9 && hour <= 18) {
  // ...
}

// CORRECT — convert to local first
var hour = DatePart(DateAdd(Now(), -3, "h"), "h");  // ART = UTC-3
if (hour >= 9 && hour <= 18) {
  // ...
}

// BEST — use SystemDateToLocalDate which honors the tenant's
// configured timezone (DST-aware)
var localNow = Platform.Function.SystemDateToLocalDate(Now());
var hour = DatePart(localNow, "h");

SystemDateToLocalDate is the right answer in multi-BU or DST-sensitive contexts because it reads the tenant's configured timezone instead of hardcoding an offset that breaks at DST boundaries.

`DateAdd(date, n, "m")` (months) is unstable around month boundaries

Same as SQL's DATEADD(month, ...) — adding/subtracting months from a date that doesn't have a counterpart in the target month produces engine-dependent results (Feb 28 vs Feb 29, May 31 → Feb 28, etc.).

// AT RISK — month math, edge cases around year boundaries
var threeMonthsAgo = DateAdd(Now(), -3, "m");

// STABLE — day-count math, behaves the same every run
var ninetyDaysAgo = DateAdd(Now(), -90, "d");

If the business rule is "last 3 months", translate to a day count once at design time and document the conversion in a comment. See SSJS gotchas (cross-applies the same SQL #8 discipline).

`DatePart(date, "n")` for minutes — the cryptic one

The naming convention isn't intuitive. Month is "m", minute is "n". Using "m" when you meant "n" returns the month number when you wanted the minute. The error is silent because the script runs and returns a valid integer, just the wrong one.

// BUG — "m" returns month number (1-12), not minute (0-59)
var mins = DatePart(Now(), "m");
// At 14:23 in May, returns 5, not 23.

// CORRECT
var mins = DatePart(Now(), "n");

Memorize the table or copy from a snippet — don't try to guess.

Native `new Date(year, month, ...)` uses 0-indexed months; `DatePart` and `FormatDate` use 1-indexed

This is the single most common SSJS date bug at Cleon. The native JS constructor treats 0 as January, 11 as December. DatePart(d, "m") returns 1 for January, 12 for December. FormatDate(d, "MM") likewise returns 01 for January.

// AT RISK — constructor expects monthIndex (0-based)
var jan = new Date(2026, 1, 15);    // → February 15, NOT January 15
var dec = new Date(2026, 12, 15);   // → January 15, 2027 (rolls over!)

// CORRECT
var jan = new Date(2026, 0, 15);    // → January 15
var dec = new Date(2026, 11, 15);   // → December 15

// AT RISK — inverse: passing DatePart-style 1-indexed value back to constructor
var monthFromDate = DatePart(someDate, "m");  // 5 for May
var sameMonth = new Date(2026, monthFromDate, 1);
// → June 1 (because May=4 in constructor land, 5 = June)

// CORRECT
var sameMonth = new Date(2026, monthFromDate - 1, 1);

The discipline: never pass a value between the DatePart/format world (1-indexed) and the constructor world (0-indexed) without subtracting/adding 1 explicitly.

WATCH OUT

DateDiff(start, end, part) returns whole units by truncation, not rounding. DateDiff(noon, midnight + 23h59m, "d") returns 0, not 1. This matters for "X days ago" calculations where the boundary feels like a day but isn't quite a 24-hour difference.

// At 11:59pm, "started yesterday at 12:01am" returns 0 days, not 1
var start = new Date("2026-05-07T00:01:00Z");
var now = new Date("2026-05-07T23:59:00Z");
DateDiff(start, now, "d");   // → 0

// For "calendar days difference" (date-only, no time component)
var sDay = new Date(start.getFullYear(), start.getMonth(), start.getDate());
var eDay = new Date(now.getFullYear(),   now.getMonth(),   now.getDate());
DateDiff(sDay, eDay, "d");   // → still 0 in this case, but consistent across day boundaries

Date strings: ISO 8601 only — anything else is locale-dependent

Constructing a Date from a string that isn't ISO 8601 ("2026-05-08T14:23:11Z") gives engine-dependent results. new Date("05/08/2026") is May 8 in some locales, August 5 in others. Always use ISO format when the string crosses a tenant boundary or comes from external data.

// AT RISK — locale-dependent parse
var d = new Date("05/08/2026");

// SAFE — ISO 8601, unambiguous
var d = new Date("2026-05-08T00:00:00Z");

// For date-only without time, append T00:00:00Z to keep the time portion explicit
var d = new Date("2026-05-08T00:00:00Z");

Quick decision

Use Now() when:

You need the current UTC moment for a calculation, log timestamp, or DateAdd/DateDiff input.

Use Platform.Function.SystemDateToLocalDate(Now()) when:

The result of the calculation is for a user (display, send-window logic, business-day math) and the tenant's local timezone matters.

Use DateAdd(date, n, "d") (days) instead of (...,"m") (months) when:

The interval doesn't need to follow the calendar exactly.
"Last 3 months" → 90 days. Document the conversion.

Use DatePart(date, "n") for minutes — never "m". Always.

Use new Date(yyyy, mm-1, dd) (subtract 1!) when:

Constructing a date from year/month/day integers.

Use Platform.Function.FormatDate(d, "yyyy-MM-dd", loc) when:

Outputting a date string to a user, file name, or log message. Pick ISO format unless the locale specifically requires otherwise.

Basics — SpiderMonkey 1.7 supported features
Platform.Function — Now(), FormatDate, SystemDateToLocalDate
String functions — FormatNumber / FormatDate for output
MC SSJS gotchas — see #1 (no modern JS — many Date methods missing)
MC SQL — Date functions — sibling for the SQL surface; identical UTC + month-math traps

More SSJS reference pages incoming: Encoding · Hashing · Util / Variable · Style Guide.

Plus how-to snippets for common production patterns — DE add/update/upsert, error handling, callout pagination, etc.

Official syntax

What survives in production

Now() is UTC, not your tenant's local time

DateAdd(date, n, "m") (months) is unstable around month boundaries

DatePart(date, "n") for minutes — the cryptic one

Native new Date(year, month, ...) uses 0-indexed months; DatePart and FormatDate use 1-indexed