Architect Expression DateTimeDiff returning null vs GetDayOfWeek

Does anyone know why my Architect expression fails to evaluate correctly when using DateTimeDiff? I am trying to calculate the difference in days between a custom datetime attribute and the current timestamp to trigger a specific routing logic. According to the documentation: “DateTimeDiff returns the difference between two date/time values in the specified unit.” My expression looks like this: DateTimeDiff(${contact.attributes.custom_date}, ${now()}, 'days'). However, the result is consistently null or throws a parsing error in the flow logs, even though both inputs are valid ISO 8601 strings. I have verified the data types via the debug panel, and they appear correct.

I noticed that simpler functions like GetDayOfWeek(${now()}) work perfectly fine in the same flow. The documentation states: “GetDayOfWeek returns the day of the week as an integer (1-7).” This works without any issues. I am confused why a basic arithmetic difference function would fail while a simple extraction function succeeds. I have tried wrapping the values in ToString and ParseDateTime, but the expression evaluator still returns null. Is there a specific format requirement for the datetime strings in DateTimeDiff that is not mentioned in the standard docs?

Here is the exact error from the flow execution log: Expression evaluation error: Cannot convert 'null' to type 'System.Int32'. I am using the latest Architect version. My C# background suggests this might be a type coercion issue, but the SDK does not have a direct equivalent for testing this expression locally. I am stuck on this for hours. Any help with the correct syntax or a working example of DateTimeDiff in a production flow would be appreciated. I need to know if this is a bug or a usage error on my part.

You need to verify that ${contact.attributes.custom_date} contains a valid ISO 8601 string. The API often returns null if the source attribute is empty or malformed. Use IsNull(${contact.attributes.custom_date}) to guard the logic. If the date is valid, ensure the unit argument matches the documentation exactly. Check the debug logs for type conversion errors.

Have you tried parsing the attribute explicitly using ParseDate(${contact.attributes.custom_date}, "ISO8601") before the diff calculation? Android SDK clients often serialize timestamps differently. Also, verify now() scope. I use DateTimeDiff(ParseDate(${attr.date}, "ISO8601"), Now(), "days") in Kotlin wrappers to avoid type coercion nulls.