🔍

Add Time To Attributes

Enrichments

Overview

The Add Time to attributes enrichment modifies existing DateTime attributes in your dataset by adding or subtracting a specified time duration. Unlike enrichments that create new calculated attributes, this enrichment directly updates your existing timestamp fields, making it invaluable for time zone adjustments, data corrections, and systematic time shifts across your process data. You can add seconds, minutes, hours, days, weeks, months, or years to all DateTime attributes or selectively choose which ones to modify.

This enrichment is particularly powerful for correcting systematic time recording errors, adjusting for daylight saving time changes, aligning timestamps from different systems, or shifting entire processes forward or backward in time for simulation and what-if analysis. The ability to apply filters means you can make these adjustments selectively - for example, only adjusting timestamps for cases from a specific region or time period. The enrichment preserves the original data structure while modifying the time values, maintaining all relationships and dependencies in your process model.

Common Uses

  • Time Zone Corrections: Adjust timestamps to convert between different time zones when consolidating data from global operations
  • Daylight Saving Time Adjustments: Correct for missing or doubled hours during DST transitions in historical data
  • System Clock Error Corrections: Fix systematic timestamp errors caused by incorrect system clock settings during data capture
  • Data Migration Time Shifts: Align timestamps when migrating processes between systems with different time recording standards
  • Process Simulation: Shift entire processes forward or backward in time for testing and what-if scenario analysis
  • Batch Processing Adjustments: Correct timestamps for batch-processed events that were recorded at processing time rather than actual occurrence
  • Historical Data Alignment: Synchronize timestamps from legacy systems that used different time references or epochs

Settings

Filter: Optional filter to restrict which cases are affected by the time adjustment. When no filter is applied, all cases in the dataset will have their selected DateTime attributes modified. Use filters to target specific subsets of your data, such as cases from a particular time period, region, or system. This is particularly useful when correcting time zone issues for specific locations or fixing errors that only affected certain periods of data collection. The filter uses the standard mindzie filter interface, supporting complex conditions and combinations.

Attribute Names: Select which DateTime attributes to modify. By default, if no attributes are selected, the enrichment will apply to all DateTime attributes in both case and event tables. You can select multiple specific attributes to target only the timestamps you want to adjust. This list dynamically populates with all available DateTime attributes from your dataset. Common selections include "Start_Time", "End_Time", "Created_Date", "Modified_Date", and any custom timestamp fields in your data. The enrichment will skip any null values, leaving them unchanged.

Add Value: The numeric value to add to the selected timestamps. This can be positive (to move timestamps forward in time) or negative (to move timestamps backward in time). The interpretation of this value depends on the Timespan Duration setting. For example, entering "2" with "Hours" selected will add 2 hours to all timestamps, while "-30" with "Minutes" selected will subtract 30 minutes. The value must be a whole number (integer). Consider the magnitude carefully - adding years or months can create significant shifts in your process timeline.

Timespan Duration: The unit of time for the Add Value setting. Available options are:

  • Seconds: For fine-grained adjustments or correcting sub-minute timing issues
  • Minutes: Useful for minor time corrections or adjusting for small clock differences
  • Hours: Most common for time zone adjustments (e.g., adding 5 hours for EST to UTC conversion)
  • Days: For shifting entire processes or correcting date-level errors
  • Weeks: For adjusting weekly batch processes or correcting week-based scheduling errors
  • Months: For long-term process shifts or fiscal period adjustments
  • Years: For historical data alignment or major temporal transformations

Examples

Example 1: Time Zone Conversion from EST to UTC

Scenario: A company's US East Coast operations recorded all timestamps in EST (UTC-5), but the central data warehouse requires all times in UTC for global consistency. You need to add 5 hours to all timestamps from the US operations.

Settings:

  • Filter: Region = "US-East"
  • Attribute Names: (leave empty to adjust all DateTime attributes)
  • Add Value: 5
  • Timespan Duration: Hours

Output: Original timestamps:

  • Order_Created: 2024-03-15 09:00:00 (EST)
  • Order_Approved: 2024-03-15 09:30:00 (EST)
  • Order_Shipped: 2024-03-15 14:00:00 (EST)

After enrichment:

  • Order_Created: 2024-03-15 14:00:00 (UTC)
  • Order_Approved: 2024-03-15 14:30:00 (UTC)
  • Order_Shipped: 2024-03-15 19:00:00 (UTC)

All timestamps are now aligned to UTC, enabling accurate global process analysis and avoiding confusion when comparing processes across time zones.

Insights: With standardized UTC timestamps, analysts can now accurately compare process performance across global locations, identify true bottlenecks regardless of local time zones, and create unified dashboards for worldwide operations.

Example 2: Daylight Saving Time Correction

Scenario: Historical data from March 2023 has a one-hour gap due to a daylight saving time transition that wasn't properly handled by the source system. All timestamps after March 12, 2023, 02:00 need to be adjusted backward by one hour.

Settings:

  • Filter: Start_Time >= "2023-03-12 02:00:00"
  • Attribute Names: Start_Time, End_Time, Activity_Timestamp
  • Add Value: -1
  • Timespan Duration: Hours

Output: Events incorrectly showing:

  • Activity A: 2023-03-12 03:30:00
  • Activity B: 2023-03-12 04:15:00
  • Activity C: 2023-03-12 05:00:00

After correction:

  • Activity A: 2023-03-12 02:30:00
  • Activity B: 2023-03-12 03:15:00
  • Activity C: 2023-03-12 04:00:00

The one-hour gap caused by DST is now corrected, restoring the actual sequence and duration of activities.

Insights: Correcting DST issues ensures accurate duration calculations, prevents false bottlenecks from appearing in the data, and maintains the integrity of time-based KPIs and SLA measurements.

Example 3: System Migration Time Alignment

Scenario: During a system migration, all timestamps from the legacy system (which used a different epoch) need to be shifted forward by exactly 30 days to align with the new system's time reference.

Settings:

  • Filter: Source_System = "Legacy_ERP"
  • Attribute Names: (leave empty for all attributes)
  • Add Value: 30
  • Timespan Duration: Days

Output: Legacy system dates:

  • Case_Start: 2024-01-01 08:00:00
  • First_Approval: 2024-01-02 10:00:00
  • Final_Completion: 2024-01-05 16:00:00

After alignment:

  • Case_Start: 2024-01-31 08:00:00
  • First_Approval: 2024-02-01 10:00:00
  • Final_Completion: 2024-02-04 16:00:00

All legacy system timestamps are now properly aligned with the new system's time reference, allowing seamless process analysis across both systems.

Insights: Proper time alignment enables accurate process comparison before and after migration, validates that the new system maintains expected process performance, and ensures historical trending remains valid.

Example 4: Batch Processing Time Correction

Scenario: A batch processing system recorded all events at the batch run time (midnight) rather than their actual occurrence times. Events need to be distributed throughout the day by subtracting hours based on their sequence.

Settings:

  • Filter: Batch_Processed = "True" AND Processing_Sequence >= 6
  • Attribute Names: Event_Timestamp, Activity_Time
  • Add Value: -6
  • Timespan Duration: Hours

Output: Batch recorded times (all at midnight):

  • Order_Received: 2024-03-15 00:00:00
  • Order_Validated: 2024-03-15 00:00:00
  • Order_Approved: 2024-03-15 00:00:00

After correction for sequence 6+ events:

  • Order_Received: 2024-03-14 18:00:00
  • Order_Validated: 2024-03-14 18:00:00
  • Order_Approved: 2024-03-14 18:00:00

Events are now distributed across the actual day they occurred, though multiple enrichment passes may be needed for complete distribution.

Insights: Correcting batch processing timestamps reveals true process patterns, enables accurate duration and throughput calculations, and helps identify actual peak periods rather than artificial batch processing spikes.

Example 5: Fiscal Year Adjustment

Scenario: A company needs to shift all timestamps forward by 3 months to align calendar year data with their fiscal year (which starts in April) for financial process analysis.

Settings:

  • Filter: (none - apply to all cases)
  • Attribute Names: (leave empty for all attributes)
  • Add Value: 3
  • Timespan Duration: Months

Output: Calendar year timestamps:

  • Q1_Start: 2024-01-01
  • Q1_Transaction: 2024-02-15
  • Q1_Close: 2024-03-31

Fiscal year aligned:

  • Q1_Start: 2024-04-01
  • Q1_Transaction: 2024-05-15
  • Q1_Close: 2024-06-30

All timestamps now align with the fiscal calendar, enabling accurate financial period analysis and reporting.

Insights: Fiscal alignment allows finance teams to accurately analyze process performance by fiscal periods, compare year-over-year fiscal performance, and align process metrics with financial reporting requirements.

Output

The Add Time to attributes enrichment modifies existing DateTime attributes in place, with the following characteristics:

In-Place Modification: Unlike enrichments that create new attributes, this enrichment directly modifies the values of existing DateTime attributes. The attribute names, types, and structure remain unchanged - only the time values are adjusted.

Attribute Scope: The enrichment can modify:

  • Case attributes: DateTime fields at the case level
  • Event attributes: DateTime fields at the event level
  • All DateTime attributes when no specific selection is made
  • Only selected attributes when specifically chosen

Value Preservation: The enrichment maintains:

  • The date and time components (adjusting both appropriately)
  • The precision of the original timestamp (milliseconds are preserved if present)
  • Null values (they remain null and are not modified)
  • The data type (DateTime remains DateTime)

Filter Application: When filters are applied:

  • Only cases matching the filter criteria have their timestamps modified
  • Cases not matching the filter retain their original timestamp values
  • This creates a mixed dataset where some timestamps are adjusted and others are not

Calculation Details:

  • Seconds/Minutes/Hours/Days: Simple arithmetic addition to the timestamp
  • Weeks: Calculated as days * 7 and added to the timestamp
  • Months: Intelligent handling of month boundaries (e.g., January 31 + 1 month = February 28/29)
  • Years: Accounts for leap years automatically

Important Considerations:

  • This enrichment permanently modifies your data (within the current analysis session)
  • Consider creating a backup or copy of your dataset before applying major time shifts
  • Month and year additions handle edge cases (like February 30) by adjusting to valid dates
  • Negative values are fully supported for moving timestamps backward in time

Integration with Other Features:

  • Modified timestamps immediately affect all time-based calculations and visualizations
  • Duration calculations between activities will change if their timestamps are modified
  • Filters and dashboards using date ranges may need adjustment after time shifts
  • The modification is transparent to other enrichments - they will use the new timestamp values

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

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