Before Date Time Check FAQ

Answers to common questions about how the Before 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 less-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) later 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. Before Date Time only asserts that present values fall before 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 Before Date Time.

Anomaly Reporting

What do the anomaly messages look like?

Record Anomaly: The field '<field>' has value '<row_value>', which is not earlier than <cutoff>

Shape Anomaly: For the field '<field>', X.XXX% of N records (K) are not earlier than <cutoff>

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

Does Before 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. A scan can also roll up a large number of Record Anomalies into one Shape Anomaly.

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 Before Date Time?

Yes. Before 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 a Before 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 a Before 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 Before Date Time with After 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 Before Date Time differ from Not Future?

Before Date Time enforces a fixed cutoff across every row in the dataset. Not Future enforces a ceiling at the current moment, so its boundary moves with the clock. Use Not Future when the rule is "nothing may be dated ahead of now"; use Before Date Time when the ceiling is a specific instant, such as an archive cutoff or a period close.