Hi Tim,

It sounds like this is already a proper DATE type, so there’s no need for time or string functions. The way it’s displayed (YYYY-MM-DD vs. MM-DD-YYYY HH:MM:SS AM) is just a formatting choice, not usually how it's actually stored. In most DBMS, DATE fields are strictly typed and inherently validate as proper Gregorian dates so there’s no “format” in storage, just a native date representation.

If the goal is validation using Evaluation rules, then the usual things to check would be:
a) Missing values - are there nulls where there shouldn’t be?
b) Expected ranges - do dates fall within a logical timeframe (e.g., no orders from 1800)?
c) Common default or disallowed values - things like 1900-01-01, 9999-12-31, or placeholders that might indicate bad data.
d) Relativity & dependencies - does this date make sense in relation to others? (e.g., a ship date shouldn’t be before an order date.)
e) Uniqueness - probably not relevant unless this is actually a key field (which seems unlikely-maybe it’s just important rather than a true key).

If these dates were loaded from another source and incorrectly interpreted during ingestion, there could be a mix of issues-not just valid-looking but incorrect dates, but also records that were dropped entirely if parsing failed. That would likely have been framed as a bigger problem, though, so it’s probably not the case here.

One other possible issue is truncation or timezone shifts. If the original source included a time component and it was stripped to just a DATE, you could have unintended offsets-some systems default to midnight UTC when stripping time, which might cause subtle shifts depending on how time zones were handled. It’s an edge case, but worth considering if unexpected discrepancies show up.

Otherwise, if the field is already a strict DATE type in the DB, this is more of a standard data integrity check rather than a formatting issue.

Does that help?

Hi Tim,

In addition to what Sam already explained, there is also a distinction between a date and a datetime (or timestamp) datatype. In this case apparently the date is displayed without the time details, but it can also be displayed as date with 00:00:00 as time details.

If the business is only requesting to make sure that the values are only date values, so Tim's examples a-e don't apply, and indeed the date datatype applies for this field in the database, you can simply tell the business that their requirement is already met. 

Kind regards,

Albert

Thank you, your replies are in line with my experience.