Comparing values of DateTime-columns (with DateTimeDetail = 0) does not always work correctly. (4372170)

Comparing values of DateTime-columns (with DateTimeDetail = 0) does not always work correctly.

How to reproduce this issue:

For the column ExtensionAttribute10 in table ADSAccount define the following (overwriting) value template:

If $FK(UID_Person).TechnicalEntryDate:Date$ > Date.Today Then 
    Value = "Technical Entry Date is greater than today: " + String.Format("TechnicalEntryDate value: {0}", $FK(UID_Person).TechnicalEntryDate:Date$.ToString("MM/dd/yyyy hh:mm:ss.fffffff")) + " Today: " + String.Format("Today value: {0}", Date.Today.ToString("MM/dd/yyyy hh:mm:ss.fffffff")) 
Else 
    Value = "Technical Entry Date is less than or equal to today" 
End If

Set one employee's TechnicalEntryDate (this column has a time part, i.e. its DateTimeDetail = 0) in Front-end to today with the time-part in UTC equal to "00:00:00" (for example CEST time "6/6/2023 02:00:00 AM" corresponds to UTC time "2023-06-06 00:00:00"). Because Date.Today yields date with a time-part equal to "00:00:00", you would expect that the condition of the value template will NOT satisfy, because both dates are expected to be the same. In reality, however, because object layer adds an extra tick to the values of "Date and time" columns, which have time-part in UTC equal to "00:00:00" (and this, on the other hand is indicated by an extra second in the DB, i.e. such values will be saved in the DB with the time-part "00:00:01"), both dates have a difference of one tick and hence are not equal.

Expected result:

Dates are treated as equal.

Different result:

Dates are treated as not equal.

This is a product defect (36945).

WORKAROUND:

1. DBVal.Compare() should take this extra tick into account.
2. Value templates should be modified in order to use DBVal.Compare() for comparison.

STATUS:

This has been logged as defect #36945, and it will be fixed in a future release of the product.

36945