Could someone explain why my date comparison logic is flipping signs?
I’m building a notification trigger in Architect that checks if a ticket has been idle for more than 4 hours. The goal is simple: if the last activity timestamp is older than 4 hours, send a webhook. I’m using the DateTimeDiff function because GetDayOfWeek doesn’t give me granular hour/minute precision, and I need to avoid crossing midnight boundaries incorrectly.
The problem is the sign. When the last activity is in the past, I expect a positive number (e.g., 5 hours ago = 5). Instead, I’m getting -5. When I swap the arguments:
I get positive 5. This feels backwards compared to standard JS Date.now() - oldDate patterns where past events yield positive durations. Is this a known quirk in the Architect expression engine, or am I misreading the parameter order?
I tried wrapping it in Abs() just to make it work, but that feels like a hack. I want to understand the underlying behavior so I don’t break other logic. Also, does DateTimeDiff handle timezone offsets automatically if the ticket timestamp is UTC but the system time is Europe/Stockholm? The docs are vague on whether it normalizes to UTC before diffing or just does a raw string compare.
I’ve tested this in a sandbox flow. The webhook payload shows the diff as -4.5 when it should be 4.5. It’s messing up my threshold check > 4. Anyone else hit this? i’m tired of guessing the sign convention.
Yep, this is a known issue… The docs say “DateTimeDiff returns the difference in the specified unit between two dates.” but it doesn’t explicitly warn about the order of operands for same-day calculations in certain edge cases. i usually verify this via C# first.
You’re likely swapping the arguments or relying on implicit conversion that fails when the system clock drifts slightly. In my C# integrations, i always normalize to UTC before passing to Architect to avoid timezone flip-flops.
Try this explicit structure:
// Verify via API first
var diff = DateTime.UtcNow.Subtract(lastActivityUtc);
Console.WriteLine(diff.TotalHours); // Should be positive if lastActivity is in past
If last_activity is older, the diff should be positive. If you’re getting negative, your last_activity is technically in the future relative to system.timestamp. Check for daylight saving shifts or manual timestamp edits. i’ve seen this break webhooks in Azure Functions too. just log both values in ISO 8601 format.
Have you tried swapping the argument order in your DateTimeDiff function?
the logic is pretty straightforward but easy to mess up. you’re calculating current - past. if you put the system timestamp first, you get a positive number. if you put the last activity first, you get negative.
check your expression:
if this returns -4.2, your variables are swapped or one of them is null/defaulting to epoch. ensure {last_activity} is actually populated. if it’s empty, the diff might be huge and negative depending on how the platform handles nulls.
also, verify the timezone context. {system.timestamp} uses the org’s default timezone, but {last_activity} might be UTC. if you’re in Lagos (UTC+1) and comparing against a UTC timestamp without conversion, you’ll see a 1-hour offset error.
Variable
Expected Format
Timezone
system.timestamp
ISO 8601
Org Default
last_activity
ISO 8601
UTC (usually)
try converting {last_activity} to local time first using ToTime before the diff. it’s annoying but necessary for accuracy.
hey. the suggestion above is spot on regarding operand order, but you’re likely tripping over timezone normalization. DateTimeDiff expects ISO 8601 strings with explicit offsets. if your last_activity field is just a naive timestamp, the engine might default it to UTC while {system.timestamp} is local, creating that phantom negative drift. wrap your inputs in DateTimeFormat to force UTC alignment before the diff calculation. DateTimeDiff(DateTimeFormat({system.timestamp}, "yyyy-MM-dd'T'HH:mm:ss'Z'"), DateTimeFormat({last_activity}, "yyyy-MM-dd'T'HH:mm:ss'Z'"), "hours"). check your data source for timezone metadata.