Day 22 at Stafify: Ensuring Correction and Formatting of Start/End Times in Shift Assignment

Today I focused on resolving several critical issues related to the formatting and validation of start and end times in our shift assignment system. These seemingly minor formatting inconsistencies were causing significant downstream problems in scheduling calculations, time tracking integration, and reporting accuracy.

I began by conducting a thorough analysis of the existing time handling code across both our legacy Google Apps Script implementation and our new Laravel codebase. This investigation revealed several inconsistent approaches to time formatting:

1. Some components were using 12-hour AM/PM format while others used 24-hour format
2. Time zone handling was inconsistent, with some components using local time and others using UTC
3. Date and time were sometimes stored as separate fields and other times as combined timestamps
4. String formatting of times varied across different parts of the system

These inconsistencies were creating edge cases where shifts might appear correctly in one view but have incorrect durations or overlaps in another. The most problematic cases involved overnight shifts spanning midnight and shifts assigned across daylight saving time transitions.

My first step was standardizing our internal time representation. I created a comprehensive TimeHandlingService that serves as a single source of truth for all time-related operations. This service:

• Normalizes all incoming time inputs to a consistent format (24-hour UTC timestamps)
• Provides methods for formatting times for display based on user preferences and locales
• Handles complex calculations like shift duration that properly account for overnight spans
• Manages time zone conversions with awareness of daylight saving transitions
• Enforces validation rules for minimum/maximum shift durations and required rest periods

For the database layer, I modified our shift tables to consistently store start and end times as UTC timestamps while adding a separate column to track the intended display time zone. This approach ensures accurate duration calculations while preserving the manager’s scheduling intent.

A major part of today’s work involved implementing correction logic for existing shift records. Many historical shifts had inconsistent formatting or timezone issues. I wrote a data migration script that:

1. Identifies problematic shift records using a series of validation rules
2. Applies intelligent correction algorithms based on surrounding context and patterns
3. Flags edge cases that require manual review
4. Preserves an audit trail of all corrections for compliance purposes

The script successfully corrected over 98% of problematic records automatically, with only a small number requiring manual intervention.

For the user interface, I implemented more robust time input controls that prevent many common errors. These controls:

• Provide clear visual indicators of the time format being used
• Automatically handle AM/PM toggling in 12-hour mode
• Prevent entering invalid times like “25:70”
• Show shift duration in real-time as users adjust start or end times
• Highlight potential conflicts or rule violations as times are changed

I also enhanced the validation feedback for time-related errors, replacing generic messages like “Invalid time” with specific guidance like “End time must be at least 30 minutes after start time” or “This shift would exceed the maximum allowed 12-hour duration.”