After Date Time Check FAQ

Answers to common questions about how the After Date Time check evaluates timestamps, how it handles NULLs and time zones, and how anomalies are reported, grouped by topic.

Behavior

Is the cutoff inclusive or exclusive?

Exclusive. The check uses strict greater-than (>), so a row whose value equals the cutoff is flagged. If you need inclusive semantics (>=), set the cutoff earlier than the value you want to allow: the preceding minute in the form, which is as fine as the picker goes, or an exact instant through the API when that extra minute would let too much through. On a Date field, one day earlier is the natural step.

How are NULL values treated?

NULLs pass. A row with NULL in the evaluated field is not counted as a violation. After Date Time only asserts that present values fall after the cutoff. If the field must also be populated, pair the check with a Not Null check on the same field.

What happens when the cutoff date and the field have different time zones?

The cutoff is stored as a UTC instant, and the comparison runs in UTC. Timestamp fields that carry an explicit time zone are compared directly; values without one are interpreted as UTC (a Date counts as midnight UTC of that day). When the source data was written in a local or mixed time zone, normalize the field upstream with a Computed Field so the boundary is unambiguous.

Does the filter run before or after the comparison?

Before. The platform applies the filter first and then evaluates the comparison only on the rows that pass the filter. Filtered-out rows cannot trigger an anomaly and are not counted in the totals.

Can the field be a String that looks like a date?

The UI restricts the field picker to Date and Timestamp columns, so the answer is effectively no. If the source column is stored as a string, expose it as a native Timestamp upstream (or with a Computed Field) before running After Date Time.

Anomaly Reporting

What do the anomaly messages look like?

Record Anomaly: <field> has the value <value>, which is not later than <limit>

Shape Anomaly: <field> values are not later than <limit>, affecting N of M asserted records

When a filter is set, the message names it at the end of its first sentence, as (applied to records where <expression>). Record and Shape Anomaly messages both carry it.

Does After Date Time produce Record Anomalies, Shape Anomalies, or both?

At 100% coverage (the default), violating rows are reported as Record Anomalies. Below 100% coverage, a failed coverage assertion produces one Shape Anomaly for the dataset.

Scan settings can group a large number of Record Anomalies into one rolled-up Shape Anomaly, which carries the Shape Anomaly message. This behavior applies across rule types and is documented under Maximum Record Anomalies per Check.

Why is the cutoff in the message shown as an ISO-8601 string with a Z suffix?

The cutoff is stored as a UTC instant and the anomaly messages echo that ISO-8601 string. The Date field in the UI takes the value in UTC (the input carries a UTC suffix), so the value you type is the instant that is persisted and shown in the message.

Does Custom Anomaly Description work for After Date Time?

Yes. After Date Time emits Record Anomalies, so the anomaly_message_field payload field (and the Custom Anomaly Description toggle in the UI) applies.

When the option points at another column on the same row, the Record Anomaly message becomes that column's value for the violating row, shown as written. When the column is null, missing, or empty, the message falls back to the rule's standard wording, and when the column is masked the message reads <masked>. Shape Anomaly messages are unaffected.

Configuration

Can I lower the coverage on an After Date Time check?

Yes. Coverage at 1.0 (100%) means every row must pass. Lowering coverage to 0.995 allows up to 0.5% of rows to fail without raising an anomaly; once the failing fraction goes past that, the check reports a Shape Anomaly. Use lower coverage with care: a real regression that happens to fall just under the threshold will not raise an alert at all.

Can I change the cutoff date on an existing check?

Yes. In the UI, open the check, change the Date property, and click Update; see Edit a Check for the full steps. Through the API, a PUT to /api/quality-checks/{id} updates properties.datetime (along with most other fields). The rule type, the target container, and the associated Check Template stay immutable; see the API page for the editable/immutable matrix.

What permission do I need to create or edit an After Date Time check?

The Drafter team permission on the datastore covers Draft work (creating a check as Draft or editing it while it stays Draft). Anything that puts the check into evaluation, such as creating or editing an Active check, archiving, or deleting, requires the Author team permission (or above). Viewing only requires Reporter. See Permissions for the full matrix.

How do I enforce both a lower and an upper time bound?

Two options:

• Pair After Date Time with Before Date Time on the same field. Each rule handles one side of the window.
• Use Between when the window is fixed; prefer the After/Before pair when the two bounds are managed independently.

How does After Date Time differ from Freshness?

After Date Time enforces a fixed cutoff across every row in the dataset. Freshness asserts that the most recent value is within an interval of the current time, so the boundary moves with the clock. Use Freshness when the question is "is this data recent enough"; use After Date Time when the question is "is this value after a specific moment in time".