How After Date Time Checks Work

This page covers everything the After Date Time check does, in detail: how it decides which rows are violations, how NULLs are handled, how the cutoff is compared against the field value, the resulting anomaly, and how the rule relates to other time-boundary rule types.

If you only need a quick reference, the Introduction page covers the formal definition, field scope, and general/anomaly properties. This page is the detailed reference.

Evaluation Flow

Every After Date Time check follows the same four-step evaluation flow:

Apply the filter clause. If the check has a filter set, only rows matching the filter expression continue to the next step. Rows outside the filter are ignored and cannot contribute to the violation count.
Read the field value as a timestamp. The platform interprets each row's value as a timestamp for comparison; values that cannot be interpreted are treated as failing the comparison (see below).
Compare against the cutoff. The cutoff (stored as a UTC instant) is compared to the field value using strict greater-than (>). A row passes only when the field value is strictly later than the cutoff.
Report violations. Each row that fails the comparison contributes to the anomaly count and produces a Record Anomaly. If the violating fraction crosses the coverage threshold, a Shape Anomaly is emitted in addition.

The comparison is strict, so a row whose field value equals the cutoff is flagged. To get inclusive semantics, set the cutoff one second (for timestamps) or one day (for dates) earlier than the boundary you want to allow.

NULL Handling

The check passes NULL values: a row with NULL in the evaluated field is not counted as a violation. This is intentional. After Date Time only asserts that present values fall after the cutoff and does not enforce mandatory presence on the field.

If the field must also be populated, pair After Date Time with a Not Null check on the same field. Together they enforce "the field must be present AND must be later than the cutoff".

Values that cannot be interpreted as a timestamp are flagged as violations. Because the field picker accepts only Date and Timestamp columns, this rarely happens in practice.

Cutoff and Time Zone Behavior

The cutoff is stored as a UTC instant. When you set the cutoff to 2025-12-01 06:15:00 in the UI, the platform records it as 2025-12-01T06:15:00Z and uses that exact instant for every evaluation.

The platform interprets the field side using its configured session time zone:

Timestamp fields stored with explicit time zone offsets are compared directly against the UTC cutoff.
Naive Timestamp fields (no explicit zone) are treated according to the session time zone and converted to instants before comparison.
Date fields are interpreted as the start of that calendar day in the session time zone, then compared to the cutoff instant.

If your source data carries values in mixed or local time zones, normalize the field upstream with a Computed Field before running After Date Time so the comparison is unambiguous.

The Filter Clause

The filter clause is a SQL WHERE expression applied before the evaluation. Filtered-out rows are ignored entirely (they cannot trigger a violation and are not counted in the totals).

Common uses:

Restricting the boundary to a subset of the dataset (tenant_id = 42, status = 'active').
Excluding known-bad legacy rows that are tracked by a separate clean-up task.
Scoping the check to a partition (event_date >= '2025-12-01').

When a filter is set, both the Record Anomaly and the Shape Anomaly messages end with [filter: <expression>] so the evaluated scope is visible in the alert.

Coverage and Tolerance

Coverage is a fractional value between 0 and 1 that sets the threshold for emitting a Shape Anomaly:

1.0 (100%): every row in the filtered set must pass. Any violating row fires a Shape Anomaly for the dataset, together with one Record Anomaly per failing row. This is the default and the strictest setting.
< 1.0: the check tolerates a fraction of violating rows before a Shape Anomaly fires. Record Anomalies still describe each individual failing row.

Lower coverage values are useful when a small, known fraction of pre-cutover rows is expected (for example, during a slow migration). Use coverage carefully: a 0.5% tolerance can mask a real regression that happens to fall just under the threshold.

The Resulting Anomalies

After Date Time produces both Record Anomalies (one per violating row) and Shape Anomalies (one per dataset, when the violation rate crosses the coverage threshold). The two templates are:

Record Anomaly

The field '<field_name>' has value '<row_value>', which is not later than <cutoff>

Shape Anomaly

For the field '<field_name>', X.XXX% of N records (K) are not later than <cutoff>

When a filter is set, both Record and Shape Anomaly messages end with [filter: <expression>].

What the numbers mean

X.XXX%: the fraction of filtered rows that fail the comparison.
N: the total number of rows the check evaluated (after the filter, if any).
K: the number of rows that fail the comparison.

Source Records Behavior

The offending cell is highlighted with an orange outline and a warning-tinted background in the Source Records view, mirroring the platform's standard violation rendering. Only the cell carrying the violating value is highlighted; the rest of the row renders normally.

Custom Anomaly Description

After Date Time supports Custom Anomaly Description because it emits Record Anomalies. When anomaly_message_field (or the Custom Anomaly Description toggle in the UI) is set to another column on the same row, the Record Anomaly message is replaced by the value of that column for the violating row. The Shape Anomaly always uses the fixed template.

Relationship with Other Rule Types

After Date Time is part of a small family of time-boundary rule types. Use them together when a single boundary is not enough.

Rule Type	Why pair it with After Date Time
Before Date Time	After Date Time defines a lower bound; Before Date Time defines an upper bound. Pair them to enforce an open time window (`cutoff_low < field < cutoff_high`). Both comparisons are strict.
Between	Same effect as pairing After Date Time + Before Date Time, but expressed as a single rule. Prefer Between when the window is fixed; use the After/Before pair when the bounds are managed independently.
Not Future	Enforces an upper bound at the current moment. Pair with After Date Time to require that timestamps fall after a historical cutoff AND not in the future.
Not Null	After Date Time passes NULL values. Add a Not Null check to require presence in addition to the boundary.
Freshness	Asserts that the most recent value is within an interval of the current time. After Date Time enforces a fixed cutoff across all rows. Choose Freshness when the bound is "recent enough" and After Date Time when it is "after a specific moment".

Performance Considerations

After Date Time evaluates one column with a > comparison, so it is one of the cheaper rule types to run. The cost scales linearly with the number of rows that pass the filter. Two practical implications:

A filter that narrows the dataset to the rows you actually care about (today's partition, a single tenant, only active rows) reduces the work proportionally.
Comparisons on a native Timestamp column are cheaper than re-interpreting a non-typed value at scan time. If the upstream column is a string, project it through a Computed Field with Timestamp type so each scan reuses the already-typed value.

Introduction: formal definition, field scope, and general/anomaly properties.
Examples: three production scenarios with sample data and resulting anomalies.
API: payload shape and field notes for creating an After Date Time check programmatically.
FAQ: short answers to the most frequent questions.