🔍

Correct Time Zone

Enrichments

Overview

The Correct Time Zone enrichment automatically adjusts all timestamps in your process mining dataset from UTC (Coordinated Universal Time) to a specified local time zone. This enrichment is essential when analyzing processes that span multiple geographic regions or when your source systems store timestamps in UTC format that need to be converted to local business hours for accurate analysis.

This enrichment performs a comprehensive conversion across your entire dataset, transforming all date/time values in both case attributes and event attributes to reflect the correct local time zone. This ensures that time-based analyses, such as working hours calculations, shift analysis, and daily/weekly patterns, accurately reflect the business reality in the local time zone where the processes actually occur.

Common Uses

  • Convert UTC timestamps from global ERP systems to local business time zones for accurate working hours analysis
  • Align timestamps from multiple source systems that use different time zone conventions into a single, consistent local time
  • Prepare data for shift-based analysis by ensuring all timestamps reflect the actual local time when work was performed
  • Enable accurate calculation of business hours metrics by converting to the time zone where the process operates
  • Support compliance reporting that requires timestamps in specific regional time zones
  • Facilitate cross-regional process comparison by standardizing timestamps to headquarters' time zone
  • Correct timestamp display for business users who need to see events in their local time rather than system time

Settings

This enrichment operates automatically using the time zone configuration specified at the dataset level. No additional settings are required in the enrichment itself.

Dataset Time Zone: The target time zone for conversion is configured when importing or configuring your dataset in mindzieStudio. The enrichment reads this configuration and applies it consistently across all timestamps. Common time zones include:

  • Eastern Standard Time
  • Pacific Standard Time
  • Central European Time
  • Greenwich Mean Time
  • Australia Eastern Standard Time
  • And all other standard Windows time zone identifiers

Automatic Detection: The enrichment automatically identifies all date/time columns in your dataset (both in case attributes and event attributes) and converts each timestamp from UTC to the specified local time zone. Only timestamps that have a time component (not just dates) are converted.

Skip If Already Local: If your dataset has already been converted to local time (indicated by the IsLocalTime flag), this enrichment will skip processing to avoid double conversion.

Examples

Example 1: Global Manufacturing Process Analysis

Scenario: A multinational manufacturing company has factories in Germany, China, and Mexico, all reporting to a SAP system that stores timestamps in UTC. The European headquarters needs to analyze production processes in Central European Time to align with business reporting.

Settings:

  • Dataset Time Zone: Central European Standard Time
  • No additional enrichment settings required

Output: Original UTC timestamps are converted to CET/CEST:

  • UTC Event: 2024-03-15 14:30:00 becomes CET: 2024-03-15 15:30:00 (winter time)
  • UTC Event: 2024-07-15 14:30:00 becomes CEST: 2024-07-15 16:30:00 (summer time)

All case attributes with timestamps (Order Date, Delivery Date, Payment Date) and event timestamps are automatically adjusted. This enables accurate analysis of working hours (8:00-17:00 CET) and identification of overtime work.

Insights: After conversion, the company discovers that what appeared to be late-night production activities (22:00 UTC) were actually normal afternoon shifts (15:00 local time) in their Mexico facility, eliminating false compliance alerts.

Example 2: Healthcare Appointment Scheduling

Scenario: A hospital network spans three time zones across the United States. Their centralized scheduling system stores all appointment times in UTC, but local staff need to see appointments in their respective local times for operational planning.

Settings:

  • Dataset Time Zone: Eastern Standard Time (for East Coast analysis)
  • No additional enrichment settings required

Output: Patient journey timestamps converted from UTC to EST/EDT:

  • Registration: 2024-02-20 18:00:00 UTC → 2024-02-20 13:00:00 EST
  • Appointment: 2024-02-20 19:30:00 UTC → 2024-02-20 14:30:00 EST
  • Discharge: 2024-02-20 21:45:00 UTC → 2024-02-20 16:45:00 EST

Insights: The conversion reveals that most appointments occur during standard business hours (9:00-17:00 EST), not in the evening as the UTC timestamps suggested. This helps in proper staff scheduling and resource allocation.

Example 3: Financial Trading Process

Scenario: An investment firm processes trades globally with all transactions logged in UTC. For regulatory compliance and performance analysis, they need to convert timestamps to New York time (EST/EDT) to align with market hours.

Settings:

  • Dataset Time Zone: Eastern Standard Time
  • No additional enrichment settings required

Output: Trade execution timestamps adjusted for NYSE trading hours:

  • Trade Initiated: 2024-03-10 13:30:00 UTC → 2024-03-10 09:30:00 EDT (market open)
  • Trade Executed: 2024-03-10 13:31:15 UTC → 2024-03-10 09:31:15 EDT
  • Settlement Confirmed: 2024-03-10 20:00:00 UTC → 2024-03-10 16:00:00 EDT (market close)

Insights: After time zone correction, the firm can accurately identify trades executed during regular market hours versus after-hours trading, enabling proper fee calculation and compliance reporting.

Example 4: E-commerce Order Fulfillment

Scenario: An online retailer with fulfillment centers worldwide needs to analyze order processing times in Pacific Time to align with their headquarters' business hours and customer service operations.

Settings:

  • Dataset Time Zone: Pacific Standard Time
  • No additional enrichment settings required

Output: Order lifecycle timestamps converted from UTC to PST/PDT:

  • Order Placed: 2024-08-15 05:00:00 UTC → 2024-08-14 22:00:00 PDT (previous day)
  • Payment Processed: 2024-08-15 05:15:00 UTC → 2024-08-14 22:15:00 PDT
  • Warehouse Picked: 2024-08-15 15:00:00 UTC → 2024-08-15 08:00:00 PDT
  • Shipped: 2024-08-15 23:00:00 UTC → 2024-08-15 16:00:00 PDT

Insights: The time zone correction shows that orders appearing to be placed at 5 AM UTC were actually placed at 10 PM PST the previous evening, explaining high overnight order volumes and helping optimize warehouse staffing for morning pick operations.

Example 5: IT Service Desk Operations

Scenario: A global IT service provider needs to analyze incident resolution times across multiple regions. Their ITSM system logs all events in UTC, but SLA compliance must be measured in local business hours.

Settings:

  • Dataset Time Zone: GMT Standard Time (for UK operations analysis)
  • No additional enrichment settings required

Output: Incident timestamps converted from UTC to GMT/BST:

  • Incident Created: 2024-06-20 08:00:00 UTC → 2024-06-20 09:00:00 BST
  • First Response: 2024-06-20 08:45:00 UTC → 2024-06-20 09:45:00 BST
  • Escalated: 2024-06-20 11:00:00 UTC → 2024-06-20 12:00:00 BST
  • Resolved: 2024-06-20 15:30:00 UTC → 2024-06-20 16:30:00 BST

Insights: Converting to local time reveals that most incidents occur during UK business hours (9:00-17:00 BST), not early morning as UTC times suggested, validating current shift patterns and identifying peak support demand periods.

Output

The Correct Time Zone enrichment modifies all existing date/time attributes in your dataset without creating new columns. The conversion affects:

Case Attributes:

  • All date/time fields in the case table are converted from UTC to the specified local time zone
  • Examples include: Case Start Time, Case End Time, Order Date, Due Date, Completion Date
  • Only timestamps with time components are converted (pure dates without times remain unchanged)

Event Attributes:

  • All date/time fields in the event table are converted to local time
  • The primary Timestamp field used for process mining is adjusted
  • Any additional timestamp fields (Start Time, End Time, Schedule Time) are also converted

Data Integrity:

  • The relative order of events remains unchanged
  • Duration calculations between timestamps remain accurate
  • The enrichment sets an internal flag (IsLocalTime) to prevent accidental re-conversion

Integration Notes:

  • Once converted, all time-based enrichments and calculators will use the local timestamps
  • Filters based on time ranges will operate on local time values
  • Export functions will output the converted local timestamps
  • The conversion accounts for daylight saving time changes automatically

See Also

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

An error has occurred. This application may no longer respond until reloaded. Reload ??