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.
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:
… 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?
