Architect Data Action: DateTimeDiff returning NaN for JST timestamps

Architect & Flows
1

Getting NaN when trying to calculate the difference in minutes between two timestamps in a Genesys Cloud Architect Data Action.

We’re running a Node.js backend that pushes interaction metadata to GC via the /api/v2/interactions endpoint. The timestamps are ISO 8601 strings in UTC, but our business logic requires checking if the interaction happened within the last 15 minutes of JST business hours.

I’ve got a Data Action set up with these parameters:

{
 "name": "CheckRecentInteraction",
 "type": "data",
 "expression": "DateTimeDiff([CurrentTime], [InteractionTimestamp], 'minutes')"
}

The issue is that DateTimeDiff seems to ignore the timezone context entirely or parses the string incorrectly when it hits the T separator. If I pass 2023-10-27T10:00:00.000Z, the result is garbage.

I tried using GetDayOfWeek([InteractionTimestamp]) as a sanity check to see if the parser is even recognizing the date string, but that also returns null or an error.

Here’s the kicker: if I hardcode the timestamp in the Data Action expression like DateTimeDiff([CurrentTime], '2023-10-27 10:00:00', 'minutes'), it works fine. But as soon as I swap it for the dynamic variable [InteractionTimestamp] coming from the webhook payload, it breaks.

Is there a specific format requirement for date strings passed into Architect expressions via REST? The docs say it accepts ISO 8601, but maybe the Node SDK is stripping the timezone info or adding extra milliseconds that the expression engine chokes on?

I’ve verified the payload hitting the GC API is clean:

{
 "timestamp": "2023-10-27T10:00:00.000Z"
}

Also tried formatting it in JS before sending:

const isoDate = new Date().toISOString().replace('T', ' ').slice(0, 19);

That didn’t help either.

Anyone else hit this wall with dynamic date comparisons in Data Actions? The expression engine feels pretty brittle when it comes to string-to-date parsing from external sources. We’re in Asia/Tokyo, so maybe there’s some weird local timezone offset being applied server-side that I’m not accounting for?

Just need to get the minute diff calculation working reliably. Can’t have the routing logic failing because of a timestamp parse error.

2

The issue is almost certainly how Architect handles the string-to-date conversion internally, especially when timezones are involved. DateTimeDiff expects actual Date objects, not ISO strings. If you’re passing strings directly, it often chokes and returns NaN.

You need to parse the strings into Date objects first using ParseDateTime before feeding them into DateTimeDiff. Here’s the sequence I use in my data actions:

  1. Use ParseDateTime on your incoming ISO string.
  2. Feed the result into DateTimeDiff.

It looks something like this in the Architect flow:

{
 "actions": [
 {
 "key": "parseStart",
 "type": "ParseDateTime",
 "parameters": {
 "value": "${interaction.startTimestamp}",
 "format": "iso8601"
 }
 },
 {
 "key": "calcDiff",
 "type": "DateTimeDiff",
 "parameters": {
 "date1": "${parseStart.result}",
 "date2": "${interaction.endTimestamp}",
 "unit": "minutes"
 }
 }
 ]
}

Also, keep in mind that DateTimeDiff calculates the difference in the system’s local time context unless you explicitly handle the offset. If your backend is pushing UTC but you need JST logic, you might need to adjust the timestamp before parsing or just handle the timezone offset in your Node.js backend before sending it to GC. Architect’s datetime functions aren’t great with mixed timezone arithmetic.

Check if parseStart.result is actually a valid date object in the trace. If it’s null, the diff will definitely be NaN.