Time Component Analysis

Time fields often have a default time of midnight (00:00, 12:00AM) or noon (12:00, 12:00PM). This can be the default value before it's changed to an actual time, or the value that is entered when only a date was given for example. The Time Component analysis scans date-time fields, and classifies each value as either midnight/noon (Default), or different (non-Default). A high midnight/noon percentage might indicate the time component is not being used meaningfully, and the field may effectively contain only date information. The analysis runs in the context of the current user's timezone, meaning that users who run the analysis in different time zones might get different results.

Use this analysis to determine whether the time portion of a date-time field carries meaningful information, or whether the field is effectively being used as a date-only field.

Configuration

Set thresholds for what constitutes a good, warning level, or critical Default percentage. For most fields that you apply a Time Component analysis to you'll want to have as few fields with a time set to 00:00/12:00 as possible. This would mean for example a good Default rate is 10% or less, warning level would be between 10-15%, and anything more than 15% would be critical.
Records with empty values are not taken into account.

Detailed Job Results

The Default Time vs Other Time Usage bar chart shows for each field the percentages of default ‘midnight' (12AM / 00:00) or ‘noon' (12PM / 12:00) values vs. different time values used.

The Field Details results table shows per field the number of records with a value ( # Records with Value), the number of records with a ‘midnight’ (12AM / 00:00) or 'noon (12PM / 12:00)' time value ( # Records with Default Time), and the records with a ‘midnight’ or 'noon' time value as a percentage of all records with a value ( % Records with Default Time). The ‘midnight/noon’ time component percentage is color-coded by the threshold settings (green for Good, amber for Warning, red for Critical).

Key Insights

• Effective field type: A high ‘Default Time' (midnight/noon) percentage suggests a date-time field is functioning as a date-only field in practice, even though the field type allows time values.
• Source of time values: Default-heavy fields often indicate data entered by integrations or imports that default to 00:00:00 or 12:00:00, while varied times typically indicate user input or systems that capture real timestamps.
• Process design signal: If a field is almost always at midnight or noon, time-of-day logic tied to that field is likely unreliable and may produce misleading results.
• AI and reporting readiness: Fields with predominantly non-default times are safer to use for time-based analysis, SLA calculations, and AI features that depend on time-of-day.

Recommended Actions

Scenario	Actions
High Default Time percentage (time portion not meaningfully used)	- Treat the field as date-only in downstream logic - Document that the time component is largely ignored for this field - Align integrations and imports to populate only the date, or standardize on midnight as a known convention - Consider whether the field could be replaced by a Date field in new designs
High non-Default percentage (time potion actively used)	- Confirm that time is intentionally used, and not simply uses a different default (e.g. a time that would be 12AM or 12PM in a different time zone) - Use confidently in time-sensitive reporting and SLA logic
Both Default and non-Default values	- Investigate which processes or integrations set default vs. actual times - Align on a single approach: either treat the field as date-only, or enforce meaningful time capture across all entry points - Update integrations, flows, and documentation to reflect the chosen standard
Preparing for AI or reporting	- Prefer fields with high non-Default usage as inputs for time-of-day analyses - Exclude or treat with caution any fields with predominantly Default values to avoid misleading conclusions