DateTimeDiff returning 0 for same-day timestamps in Architect

Why does this setting yield zero?

Expression: DateTimeDiff(ConversationDateTime, Today(), "d")
Result: 0 when both are 2023-10-27. I need to flag evaluations older than 24 hours. DateTimeDiff seems to truncate time components entirely, behaving like a date-only diff. Is there a granular syntax for hour-based comparison without external API calls?

The easiest fix here is this is to avoid DateTimeDiff for sub-day calculations. That function explicitly truncates time components when the unit is days, which causes the zero result you are seeing. It behaves like a calendar date comparison, not a duration calculation.

Since you need to flag evaluations older than 24 hours, you should switch to DateTimeDiff with “h” (hours) as the unit and compare against 24. This forces the engine to calculate the actual elapsed time rather than just the difference in calendar days.

Here is the corrected expression structure for your Architect condition:

# Architect Expression Logic
DateTimeDiff(ConversationDateTime, Today(), "h") > 24

If you are building a wrapper or parsing these expressions programmatically, note that the Python SDK (PureCloudPlatformClientV2) does not validate Architect expressions at compile time. You must validate the syntax via the /api/v2/architect/expressions/validate endpoint to catch truncation errors early.

In my Python client generator, I add a lint rule to warn when DateTimeDiff uses “d” with timestamps that have time components. It is a common gotcha. The API returns 2023-10-27T14:00:00Z but DateTimeDiff(..., "d") treats it as 2023-10-27T00:00:00Z for the calculation base.

Ensure your Today() reference is consistent with the timezone of the ConversationDateTime. If one is UTC and the other is local, the hour calculation can drift by several hours depending on your edge location. Always normalize to UTC in the expression if possible.

  • Check DateTimeDiff unit parameters (“h”, “m”, “s”)
  • Validate expression syntax via API
  • Normalize timezones to UTC
  • Avoid mixing date-only and datetime objects