After Date Time Check Examples

Three real-world scenarios that show how the After Date Time check is typically used in production: enforcing a system cutover, validating a daily ingestion window with a filter, and detecting pre-migration timestamps that should no longer exist.

System Cutover EnforcementDaily Ingestion Window with FilterDetecting Pre-Migration Survivors

The situation: BrightCart migrated its identity provider on 2025-12-01 06:15 UTC. Every row in the users table must carry a last_login_ts that is strictly later than the cutover; older timestamps mean the row was copied from the legacy system and is no longer authoritative.

Check configuration

Field	Value
Rule	After Date Time
Field	`last_login_ts`
Date	`2025-12-01 06:15 UTC`
Filter	(none)
Coverage	100%
Custom Anomaly Description	Off
Status	Active
Owner	(check creator)
Anomaly Assignee	(Identity Platform on-call)
Tags	`migration`, `auth`
Additional Metadata	`jira: DATA-1024`
Description	Login timestamps must be later than the identity-provider migration cutover.

Payload

{
    "description": "Login timestamps must be later than the identity-provider migration cutover.",
    "rule": "afterDateTime",
    "fields": ["last_login_ts"],
    "container_id": 145,
    "coverage": 1,
    "filter": null,
    "properties": {
        "datetime": "2025-12-01T06:15:00Z"
    },
    "tags": ["migration", "auth"],
    "additional_metadata": {"jira": "DATA-1024"},
    "anomaly_message_field": null,
    "template_id": null,
    "status": "Active",
    "owner_id": 7,
    "default_anomaly_assignee_id": 12
}

Sample Data

user_id	last_login_ts	email
C001	2025-12-05 18:21:00	customer031@example.com
C010	2022-03-01 10:00:00	customer040@example.com
C011	2022-03-01 10:00:00	customer041@example.com
C013	2025-12-03 09:42:00	customer043@example.com

What gets flagged

Rows C010 and C011 both carry last_login_ts = 2022-03-01 10:00:00, which is earlier than the cutover. Both rows fire a Record Anomaly and contribute to a Shape Anomaly for the dataset.

Record Anomaly

The field last_login_ts has value 2022-03-01 10:00:00, which is not later than 2025-12-01T06:15:00Z

Shape Anomaly

For the field last_login_ts, 50.000% of 4 records (2) are not later than 2025-12-01T06:15:00Z

Flowchart

graph TD
    A["No filter, evaluate all rows"] --> B["Interpret last_login_ts as timestamp"]
    B --> C{"Is last_login_ts ><br/>2025-12-01T06:15:00Z?"}
    C -->|Yes| D["Row passes"]
    C -->|No| E["Flag row.<br/>Record Anomaly per row;<br/>Shape Anomaly if rate > coverage."]

Equivalent SQL

-- Rows the After Date Time check would flag.
SELECT u.*
FROM users u
WHERE u.last_login_ts IS NOT NULL
  AND u.last_login_ts <= TIMESTAMP '2025-12-01 06:15:00 UTC';

The situation: A pipeline writes a processed_at value to every row of the events table when it lands. Today's batch must contain only rows whose processed_at is strictly later than the start of the batch window (2026-06-19 00:00 UTC). Earlier processed_at values indicate a replay or a backfill that bypassed the daily window.

Check configuration

Field	Value
Rule	After Date Time
Field	`processed_at`
Date	`2026-06-19 00:00 UTC`
Filter	`event_date = current_date()`
Coverage	100%
Custom Anomaly Description	Off
Status	Active
Owner	(check creator)
Anomaly Assignee	(Ingestion on-call)
Tags	`ingestion`, `freshness`
Additional Metadata	`jira: DATA-2045`
Description	Today's events must have processed_at after the start of today's window.

Payload

{
    "description": "Today's events must have processed_at after the start of today's window.",
    "rule": "afterDateTime",
    "fields": ["processed_at"],
    "container_id": 212,
    "coverage": 1,
    "filter": "event_date = current_date()",
    "properties": {
        "datetime": "2026-06-19T00:00:00Z"
    },
    "tags": ["ingestion", "freshness"],
    "additional_metadata": {"jira": "DATA-2045"},
    "anomaly_message_field": null,
    "template_id": null,
    "status": "Active",
    "owner_id": 7,
    "default_anomaly_assignee_id": 18
}

Sample Data (filtered to event_date = current_date())

event_id	event_date	processed_at
e-001	today	2026-06-19 02:11:00
e-002	today	2026-06-18 23:55:00
e-003	today	2026-06-19 04:47:00

Why the filter matters

The filter runs before the comparison, so yesterday's events do not influence today's window. Only rows in the current day are tested against the 2026-06-19 00:00 UTC boundary.

What gets flagged

e-002 has processed_at = 2026-06-18 23:55:00, earlier than the start-of-day cutoff for today's window, so it is the only row reported.

Record Anomaly

The field processed_at has value 2026-06-18 23:55:00, which is not later than 2026-06-19T00:00:00Z [filter: event_date = current_date()]

Shape Anomaly

For the field processed_at, 33.333% of 3 records (1) are not later than 2026-06-19T00:00:00Z [filter: event_date = current_date()]

Flowchart

graph TD
    A["Apply filter: event_date = current_date()"] --> B["Interpret processed_at as timestamp"]
    B --> C{"Is processed_at ><br/>2026-06-19T00:00:00Z?"}
    C -->|Yes| D["Row passes"]
    C -->|No| E["Flag row.<br/>Anomaly message ends with<br/>[filter: event_date = current_date()]"]

Equivalent SQL

-- Rows the check would flag in today's window.
SELECT e.*
FROM events e
WHERE e.event_date = current_date()
  AND e.processed_at IS NOT NULL
  AND e.processed_at <= TIMESTAMP '2026-06-19 00:00:00 UTC';

The situation: A warehouse migration moved historical orders data into a new schema on 1992-01-01 00:00 UTC. Every order row in the new schema is expected to carry an o_orderdate later than that boundary. NULL order dates are allowed on the unconfirmed rows produced by a separate manual process and should not be flagged.

Check configuration

Field	Value
Rule	After Date Time
Field	`o_orderdate`
Date	`1992-01-01 00:00 UTC`
Filter	(none)
Coverage	99.5%
Custom Anomaly Description	Off
Status	Active
Owner	(check creator)
Anomaly Assignee	(Warehouse Migration team)
Tags	`migration`, `historical`
Additional Metadata	`jira: DATA-3071`
Description	Migrated orders must have an order date later than the migration cutoff.

Payload

{
    "description": "Migrated orders must have an order date later than the migration cutoff.",
    "rule": "afterDateTime",
    "fields": ["o_orderdate"],
    "container_id": 318,
    "coverage": 0.995,
    "filter": null,
    "properties": {
        "datetime": "1992-01-01T00:00:00Z"
    },
    "tags": ["migration", "historical"],
    "additional_metadata": {"jira": "DATA-3071"},
    "anomaly_message_field": null,
    "template_id": null,
    "status": "Active",
    "owner_id": 7,
    "default_anomaly_assignee_id": 24
}

Sample Data

o_orderkey	o_orderdate	o_orderstatus
1	1991-12-31 10:30:00	F
2	1992-03-15 09:15:00	O
3	1991-12-14 10:25:00	F
4	(null)	unconfirmed

What gets flagged

Rows 1 and 3 fail because their o_orderdate is earlier than the cutoff. Row 4 is NULL, so it passes without firing an anomaly but still counts in the scanned total. The 50% violation rate exceeds the 0.5% tolerance, so a Shape Anomaly is emitted in addition to the two Record Anomalies.

Record Anomaly

The field o_orderdate has value 1991-12-31 10:30:00, which is not later than 1992-01-01T00:00:00Z

Shape Anomaly

For the field o_orderdate, 50.000% of 4 records (2) are not later than 1992-01-01T00:00:00Z

Flowchart

graph TD
    A["No filter, evaluate all rows"] --> B["Interpret o_orderdate as timestamp"]
    B --> C{"Is value NULL?"}
    C -->|Yes| D["Row passes"]
    C -->|No| E{"Is o_orderdate ><br/>1992-01-01T00:00:00Z?"}
    E -->|Yes| D
    E -->|No| F["Flag row"]

Equivalent SQL

-- Rows the check would flag.
SELECT o.*
FROM orders o
WHERE o.o_orderdate IS NOT NULL
  AND o.o_orderdate <= TIMESTAMP '1992-01-01 00:00:00 UTC';

Introduction: formal definition, field scope, and general/anomaly properties.
How It Works: full semantics, NULL handling, filter behavior, and edge cases.
API: payload shape and field notes for creating an After Date Time check programmatically.
FAQ: short answers to the most frequent questions.

After Date Time Check Examples

Related