Skip to content

After Date Time Check FAQ

Common questions about how the After Date Time check evaluates timestamps, how it handles NULLs and time zones, and how anomalies are reported.

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 one second (for timestamps) or one day (for dates) earlier than the value you want to allow.

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. Timestamp fields that carry an explicit time zone are compared directly. Naive Timestamp and Date fields are interpreted using the platform's configured session time zone before the comparison. When the source data carries mixed-zone values, 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: The field '<field>' has value '<row_value>', which is not later than <cutoff>

Shape Anomaly: For the field '<field>', 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>].

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

Both. Every violating row produces a Record Anomaly. When the violation rate crosses the coverage threshold, a Shape Anomaly is emitted in addition. Lowering the coverage threshold (for example to 0.995) keeps Record Anomalies per row but suppresses the Shape Anomaly when the rate stays below the threshold.

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. Even when you entered the cutoff in a local time zone in the UI, the persisted value is UTC; the anomaly message reflects that.

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) replaces the Record Anomaly message with the value of the named column on the violating row. When that column is null, missing, or empty for a violating row, the standard Record template is used instead. The Shape Anomaly always uses the fixed template.

Configuration

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

Yes. Coverage at 1.0 (100%) means every row must pass; lowering it to 0.995 allows up to 0.5% of rows to fail without firing a Shape Anomaly. Per-row Record Anomalies are still produced for every violating row, regardless of coverage. Use lower coverage with care: a real regression that happens to fall just under the threshold will not fire a Shape alert.

Can I change the cutoff date on an existing check?

Yes. A PUT to /api/quality-checks/{id} can update 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.

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".

  • Introduction: formal definition, field scope, and general/anomaly properties.
  • How It Works: full semantics, NULL handling, filter behavior, and edge cases.
  • Examples: three production scenarios with sample data and resulting anomalies.
  • API: payload example and field notes for creating an After Date Time check programmatically.