Running into a weird edge case with date math in Architect expressions. We’re trying to calculate the business days between two timestamps stored in the session data. The logic seems straightforward, but the DateTimeDiff function is behaving inconsistently compared to GetDayOfWeek.
Here’s the setup. We have two ISO strings in session data: {{session.data.startTimestamp}} and {{session.data.endTimestamp}}. I’m using an Assign Data action to compute the difference:
Expression: DateTimeDiff(session.data.endTimestamp, session.data.startTimestamp, "days")
The issue is that DateTimeDiff returns NaN when the timestamps cross a daylight saving time boundary, even though the input format is valid ISO 8601. Meanwhile, GetDayOfWeek(session.data.startTimestamp) works perfectly fine on the exact same string. It’s returning the correct integer for the day of the week.
I’ve checked the raw payload from the webhook that populates these fields. The values look clean:
{
"startTimestamp": "2023-11-04T09:00:00.000Z",
"endTimestamp": "2023-11-05T09:00:00.000Z"
}
Wait, that’s not the DST jump. Let me try a known DST boundary. US Eastern time, Nov 5, 2023.
Expression: DateTimeDiff("2023-11-05T01:30:00.000-05:00", "2023-11-05T01:30:00.000-04:00", "hours")
This returns -1. That makes sense if it treats the offset literally, but I need the absolute time difference in wall-clock hours, which should be 0 if it’s the same moment, or 1 if it’s the same wall time. Actually, I want business days. The NaN issue happens when I try to parse the result of DateTimeDiff into an integer for a subsequent calculation.
Is DateTimeDiff locale-aware in a way that GetDayOfWeek isn’t? The docs say it uses the account’s default timezone, but we’re passing explicit offsets. Why would one function respect the offset and the other choke? I’ve tried wrapping the inputs in ParseDateTime but that just adds more noise to the expression string. No error logs in the trace, just a silent failure in the downstream logic because the variable ends up as a string “NaN” instead of a number. Anyone else hit this wall with mixed timezone offsets in expressions?