Hi @rebekah_reveile,
Yes, I have seen this. But this is incorrect information. We can’t determine the input type ourselves. Search is automatically taking these values (with a 24 hours SLA) from the identity attributes startDate and endDate. And these identity attributes are not of type date, but are of type string, which is also why we don’t get errors when we perform account aggregation on the authoritative source and map these account attributes to the identity profile to startDate and endDate. These are of type string and can accept things like 2021-08-13T12:00:11.001Z, but also 2023:1:6 or 24-12-15, or 15-12-2024, or even Jun 12th 2024. It is then possible for the customer to define a transform with a dateformat and datecompare operation, to use the date in the way they receive it, to determine lifecycle states.
Perhaps a wrong assumption has been made here by the search team, by documenting that the values that we get here are dates in ISO 8601 format, because they can’t guarantee this and it is not always the case for customers. Different customers can have different values from the authoritative sources. As a consequence of this wrong assumption, if we search for !_exists_:attributes.endDate, we can still see in the results rows where there is a value for endDate visible. Hence the remark from @adamian: