Find Date Outliers

Overview

The Find Date Outliers calculator identifies date and timestamp values in your event log that fall well outside the typical range for that attribute, helping you detect data quality issues before they impact your process analysis. The calculator examines every date and timestamp attribute in your event log and flags individual cases or events whose date value is unusually early or unusually late compared to the rest of the data in the same field.

Unlike manual data inspection, this calculator systematically checks every date field in your process data to highlight potential problems that could distort your process mining analysis, such as incorrect activity timestamps, malformed data imports, or default placeholder values that were never updated.

Common Uses

  • Validate data quality after importing event logs from legacy systems or new data sources
  • Detect placeholder dates or default values that indicate incomplete data entry
  • Identify system clock errors or timezone conversion problems that create impossible timestamps
  • Find dates from test data that accidentally made it into production event logs
  • Verify that timestamp data falls within expected business operation periods
  • Quickly assess overall date field quality across all attributes before detailed analysis

Settings

This calculator requires no configuration settings. It automatically examines all date and timestamp attributes in your event log and flags values that fall well outside the typical range for each attribute.

Standard Fields:

  • Title: Optional custom title for the calculator output
  • Description: Optional description for documentation purposes

How outliers are identified:

For each date or timestamp attribute, the calculator computes upper and lower bounds from the actual data in that attribute, then flags values that fall outside those bounds. Bounds are calculated using a statistical method (Interquartile Range) so what counts as an "outlier" is relative to the rest of your data -- there are no hard-coded year cutoffs. An attribute whose values span years 2018-2024 will have different bounds than one whose values span 2010-2020.

Notes:

  • Null values are skipped. Missing dates aren't flagged as outliers by this calculator. (Use other data-quality tools to track missing values.)
  • Only date and timestamp attributes are examined. Text fields that happen to contain dates are not processed.
  • Attributes with too little variation produce no outliers. If all values in an attribute cluster tightly together, there's no meaningful "outside the typical range" to detect.

Examples

Example 1: Validating Legacy System Migration

Scenario: Your organization recently migrated invoice processing data from a 20-year-old legacy ERP system to a modern platform. Before performing process mining analysis, you want to verify that all date fields look reasonable -- in particular, you want to catch any placeholder dates (such as 1900-01-01) that may not have been converted.

Settings:

  • Title: "Invoice Data Migration Validation"
  • Description: "Check for date conversion issues from legacy system"

What you'd see:

The calculator returns a list of outlier rows. Because the legacy system used 1900-01-01 as a default "empty" value, those rows now stand out as far below the typical invoice date range and appear in the Case Outliers table. A handful of test records dated 2099-12-31 show up as far above the typical range.

Insights:

The output reveals that a substantial number of invoices carry the legacy placeholder date instead of a real date. A small number of records with far-future dates also appear, suggesting test data that wasn't cleaned out before migration. Before performing process analysis, you should work with the data team to:

  1. Correct or remove the records with placeholder dates
  2. Filter out the test records with far-future dates

This validation saves you from drawing incorrect conclusions about invoice processing times based on corrupted date data.

Example 2: Detecting System Clock Issues

Scenario: Users have reported that some timestamps in your order fulfillment process "don't make sense," with activities appearing to happen in the wrong order. You suspect there may be server clock synchronization issues or timezone conversion problems affecting event timestamps.

Settings:

  • Title: "Order Fulfillment Timestamp Validation"
  • Description: "Identify clock synchronization or timezone issues"

What you'd see:

The Event Outliers table lists each event whose activity timestamp falls far outside the rest of the data -- for example, a group of events stamped 20 years in the future. Each row identifies the case, the activity, and the suspect timestamp, so you can trace the affected workflow steps.

Insights:

When dozens or hundreds of events all carry timestamps that are far in the future by a uniform offset, that's a classic sign of a system clock error or a timezone conversion bug on the upstream system. Investigation typically traces back to a single server whose clock drifted during a maintenance window. Drilling into the outlier rows lets you identify exactly which workflow steps need their timestamps corrected before doing process mining on that period.

Example 3: Pre-Analysis Data Quality Check

Scenario: You're about to perform a comprehensive process mining analysis of your purchase-to-pay process spanning three years of data. As a best practice, you run the Find Date Outliers calculator first.

Settings:

  • Title: "Purchase-to-Pay Data Quality Scan"
  • Description: "Pre-analysis validation check"

What you'd see:

The calculator examines every date attribute in the log and returns no outlier rows -- both the Case Outliers and Event Outliers tables are empty.

Insights:

This is the best possible outcome -- a clean bill of health for your date data. Every date attribute in the dataset is tightly clustered and has no significant outliers. You can proceed with your process mining analysis knowing that timestamps will not distort your time-based metrics or process map ordering.

Output

The calculator produces two data tables. Each row represents a single outlier (one specific case or one specific event), not a per-attribute summary.

Case Outliers -- one row per case-level attribute value flagged as an outlier:

  • Case Id (Text): The case that contains the outlier value
  • Attribute Name (Text): The case attribute whose value is flagged
  • Date Value (DateTime): The actual outlier value found in that case attribute

Event Outliers -- one row per event-level attribute value flagged as an outlier:

  • Case Id (Text): The case the event belongs to
  • Activity Name (Text): The activity of the event
  • Activity Time (DateTime): When the event occurred
  • Attribute Name (Text): The event attribute whose value is flagged
  • Date Value (DateTime): The actual outlier value

If you want to count outliers per attribute (e.g., "how many invoices have a placeholder date?"), pivot the relevant table by Attribute Name in your dashboard.

Best Practices:

  • Run this calculator as the first step in any new process mining project
  • Re-run after any data imports or system migrations
  • Address outliers before creating process maps or calculating performance metrics
  • Use the calculator regularly on ongoing data feeds to catch quality degradation early

Note: The calculator only examines attributes whose data type is already date or timestamp. Text fields that happen to look like dates are not parsed or analyzed -- if you want those checked, convert them to a date attribute first.

This documentation is part of the mindzie Studio process mining platform.