Date&Time: Possible bug comparing zoned and not zones but equal data


maybe I get something wrong about Date&Time comparison but something is not making much sense to me making me believe this is a bug or requires some sort of date&time harmonization upfront.

Given the following data, shouldn’t the second row, where the zoned date&time data is ten hours ahead, actually be greater than the not zoned one? Especially considering that in row three but even more especially in row four the not zoned all of a sudden is in the past.

Certainly my brain is at fault, isn’t it?

Date&Time without Zone Date&Time with Zone Comment Evaluation
2023-10-17T16:53:08 2023-10-17T08:37:09+02:00 Zoned data in past Not Zoned in future
2023-10-17T16:53:08 2023-10-17T08:37:09+10:00 Zoned data in future Not Zoned in future
2023-10-17T16:53:08 2023-10-17T16:53:08+02:00 Both equal Not Zoned in past
2023-10-17T16:53:08 2023-10-17T16:53:08Z Both equal Not Zoned in past
$Date&Time without Zone$ > $Date&Time with Zone$ => "Not Zoned in future"
$Date&Time without Zone$ < $Date&Time with Zone$ => "Not Zoned in past"
$Date&Time without Zone$ = $Date&Time with Zone$ => "Both equal"

PS: Could it be that the Rule Node kind of does a string type comparison? despite that would make little sense, given number type comparisons work apparently, other in special special scenarios like that. Regardless of the time zone, positive / negative / zero, the non zoned date time stamp seems to be in the past.



You cannot sensibly compare Local Date&Time with Zoned Date&Time because the former is missing the timezone information. Therefore the Rule Engine can only perform a string comparison which is supported by your “Evaluation” column.

1 Like

Good morning @thor,

whilst I generally agree, shouldn’t an incompatible comparison of data types be prevented or at least throw a warning? From a mere observer / user perspective the values seem at leas semi-compatible. One just lacks the time zone, which also can have variations with or without the actual name but still be the same. Adding to this, there are different time zone variations such as GMT, CES etc…

The other “thing” I observed that the daylight saving variant is converted from +2 to +1 is quite unexpected but that might just be related to the missing information how date&time w/ or w/o is processed.

I have come across a wide variation of possible shortcomings in regards to date & time data like:

  1. Missing Value cannot set min or max value
  2. Constant Value Column does not support time zones but allows to propagage into corresponding columns
  3. Previous recognized date&time with zone is not recognized again
  4. Date&Time, when converted to a variable, is converted to a string (biggest bummer from my perspective)

… and more. I’d like to suggest to convert this topic to a collection post or close it in favor of opening a new one since we are already kind of off topic. What do you think?