DateTimeDiff returning negative values in Architect expression?

Hey folks,

Running into a weird issue with date comparisons in Architect. I’m trying to trigger a specific routing step if the current time is within 24 hours of a custom attribute last_contact_date.

I’ve set up the expression like this:

DateTimeDiff(SystemDateTime, GetCustomAttributeValue("last_contact_date"), "hours") < 24

The problem is it seems to flip the sign randomly. Sometimes it returns a positive number, sometimes negative, even when last_contact_date is clearly in the past. I’ve double-checked the timezone settings in Genesys Cloud and they match our US/Pacific office.

Is DateTimeDiff sensitive to the order of the arguments? The docs aren’t super clear on which date needs to be first. I tried swapping them:

DateTimeDiff(GetCustomAttributeValue("last_contact_date"), SystemDateTime, "hours") < 24

That just made it worse. Now I’m getting errors about invalid date formats in the logs. Any idea what’s going on?

Also, should I be using GetDayOfWeek for this? I saw someone mention it for weekend routing, but that doesn’t seem right for a 24-hour window.

Here’s the JSON payload from the webhook if it helps:

{
 "last_contact_date": "2023-10-27T14:30:00Z",
 "status": "pending"
}

The order of operands in DateTimeDiff is strict. The documentation for the Architect expression language states: “Returns the difference between the first and second date/time values.” If last_contact_date is in the future, or if SystemDateTime is parsed as a different timezone offset than your custom attribute, the sign flips.

In .NET SDK terms, this is exactly like calculating (end - start).TotalHours. If you swap them, you get a negative number. Architect doesn’t take the absolute value for you. You need to ensure the older date is the first argument.

Try swapping the arguments:

DateTimeDiff(GetCustomAttributeValue("last_contact_date"), SystemDateTime, "hours") < -24

Wait, that logic gets messy with negatives. A cleaner approach is to use Math.Abs if available, or just ensure the subtraction order matches your logic. But actually, the real issue is usually timezone parsing. SystemDateTime is UTC. If last_contact_date was stored as a local string (e.g., “2023-10-27 14:00:00”) without a ‘Z’ or offset, Architect might parse it as UTC anyway, but if it came from an API call that stripped the offset, it might default to a different baseline.

Check how you are setting last_contact_date. If you are using the Platform API to set it, make sure you are passing an ISO 8601 string with the ‘Z’ suffix.

// C# SDK example
var attribute = new ConversationRoutingAttribute
{
 Name = "last_contact_date",
 Value = DateTime.UtcNow.ToString("o"), // 'o' format includes 'Z'
 Type = "datetime"
};

If the value lacks the ‘Z’, Architect’s parser might be guessing the timezone based on the user’s profile or the org’s default, which causes the “random” flip when agents in different timezones handle the interaction. Force the UTC string format.

Also, check if SystemDateTime is actually SystemCurrentDateTime. Some older Architect versions had quirks with SystemDateTime being a static snapshot at workflow start. Use SystemCurrentDateTime to ensure you are getting the live clock value at the moment of evaluation.

The expression should be:

DateTimeDiff(SystemCurrentDateTime, GetCustomAttributeValue("last_contact_date"), "hours") > 0 && DateTimeDiff(SystemCurrentDateTime, GetCustomAttributeValue("last_contact_date"), "hours") < 24

This ensures the result is positive (current time is after last contact) and within the 24-hour window.