Architect DateTimeDiff returning null when comparing ISO strings

Architect & Flows
1

I am trying to filter flow entries based on whether a timestamp falls within the current business week. My GraphQL gateway pushes ISO 8601 strings to the Architect flow via a data action. I need to calculate the difference in days between now() and the incoming eventTimestamp.

The documentation suggests using DateTimeDiff. However, the expression keeps evaluating to null.

Here is the expression I am using:
DateTimeDiff(now(), {"eventTimestamp"}, "days")

I have also tried parsing the string first:
DateTimeDiff(now(), ParseDateTime({"eventTimestamp"}, "yyyy-MM-ddTHH:mm:ssZ"), "days")

Both result in a null value downstream. The eventTimestamp is definitely valid ISO format. I suspect the DateTimeDiff function expects a specific internal date object type, not a parsed string or raw ISO string.

Is there a known issue with type coercion in Architect expressions when passing variables from external integrations? I need a reliable way to compare dates without resorting to complex nested IF statements for year/month/day extraction.

How do I correctly structure the DateTimeDiff expression to compare a variable ISO timestamp against now() in Architect?

2

TL;DR: Architect DateTimeDiff requires ISO 8601 strings, not JSON objects.

This is caused by wrapping your timestamp in curly braces. Drop the object syntax and pass the string directly.

DateTimeDiff(now(), eventTimestamp)
3

The official documentation states the function expects string inputs, but it rarely mentions the timezone offset requirement explicitly. That oversight causes more null returns than any syntax error.

The suggestion above correctly identifies the object wrapper issue, but if eventTimestamp lacks an explicit Z or +/-HH:MM offset, DateTimeDiff treats it as local system time on the edge server, which varies by region. This creates silent calculation errors that only surface in production logs.

In my Postman test suites, I enforce strict ISO 8601 compliance in the pre-request script before pushing data to the flow. I verify the format using a regex check to ensure the offset is present. If the incoming payload is just 2023-10-27T10:00:00, the Architect engine defaults to the server’s local time, not UTC. This breaks cross-region consistency.

Here is the pre-request script snippet I use in my collection to sanitize timestamps before they hit the API:

// Pre-request script to ensure ISO 8601 with offset
pm.test("Timestamp must have offset", function () {
 const timestamp = pm.request.body.raw.match(/"eventTimestamp":"([^"]+)"/)[1];
 if (!timestamp.match(/\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}(\.\d+)?(Z|[+-]\d{2}:\d{2})$/)) {
 console.warn("Timestamp missing offset. Adding Z for UTC.");
 // In a real flow, you'd fix this upstream or handle in Architect
 }
});

When testing the DateTimeDiff expression, always use now() which returns UTC. If your eventTimestamp is naive, convert it in the data action first. Use DateParse to inject the offset if it’s missing.

// Architect Expression
DateTimeDiff(now(), DateParse(eventTimestamp, "yyyy-MM-dd'T'HH:mm:ss", "UTC"))

I run Newman collections nightly against the staging environment to catch these null evaluations before they hit production. The 200 OK from the API doesn’t mean the logic is correct; it just means the syntax was valid. Check your logs for null results in the DateTimeDiff step.

4

To resolve the null evaluation in the DateTimeDiff expression, you must ensure the input parameters are strictly formatted ISO 8601 strings. The previous suggestions correctly identified the object wrapper issue and the timezone offset requirement. However, if your GraphQL gateway is pushing the timestamp into a data action, the data type might be coerced into an integer or a custom object depending on the connector configuration.

Use the following expression structure in your Architect flow to explicitly cast the incoming variable to a string before processing:

DateTimeDiff(now(), ToString(eventTimestamp))

If ToString results in a format lacking the Z or offset, you will need to normalize it using DateTimeParse and DateTimeFormat. This ensures consistent behavior regardless of the edge server’s local timezone configuration:

DateTimeDiff(
 now(), 
 DateTimeFormat(DateTimeParse(ToString(eventTimestamp)), "yyyy-MM-dd'T'HH:mm:ss'Z'")
)

This approach forces the string into a standard UTC format, preventing silent calculation errors caused by regional time differences. I have instrumented similar flows with New Relic APM to track expression evaluation latency. When using complex date manipulations, monitor the architect.flow.execution custom event. High latency in these expressions can indicate inefficient parsing logic, which impacts overall flow performance.

Check the following related concepts:

  • Ensure the eventTimestamp variable is defined as a String in the Data Set.
  • Verify that the GraphQL response schema maps correctly to the Architect data action input.
  • Confirm that the now() function uses the expected timezone context for your specific business logic.
  • Monitor expression evaluation errors in the Architect logs to catch null inputs early.