Time Zones and UTC Standardization
Waterly ensures all data entries are stored in UTC (Coordinated Universal Time), a global time standard, to make timestamps accurate and consistent across time zones. This way, no matter the location of the facility, Waterly converts data entries to the correct local time for display and interaction, allowing operators to work seamlessly within their particular time zone.
Daylight Savings Time: A Consistent Approach
Waterly takes a standardized approach to DST to keep data consistent for all customers. This means that individual systems or users cannot customize DST handling. This ensures a unified experience across the platform. Waterly is even designed to automatically adapt for areas like Arizona, where DST isn’t observed, and for regions like northwest Indiana that follow the Central Time Zone.
NOTE: The majority of Waterly users will experience no difference during the DST 1-hour shift, either “springing forward” or “falling back.” These are utilities that collect data once daily. The systems that utilize the interval function within Waterly may observe the behavior outlined in the article. Of this subset of systems, it is likely only the systems that collect data specifically during the 2:00 AM time period will notice any adjustment of time.
DST’s Impact on Data Entry
Let us examine both DST scenarios and the designed behavior within Waterly.
Spring Forward: Missing 2:00 AM
In the spring, clocks “spring forward” by one hour, usually skipping from 1:59:59 AM to 3:00:00 AM. For regions observing DST in Waterly systems collecting data in the 2:00 AM interval, this skipped hour does not appear in the Waterly app’s interface. Operators will not see a 2:00 AM slot on that day. No data entry adjustment is needed. This avoids confusion for this one-day event and ensures smooth hourly data collection.
Fall Back: Repeated 1:00 AM
In the fall, when a digital clock reaches 1:59:59 AM, it “falls back.” Instead of advancing to 2:00 AM the clock repeats the 1:00:00 AM hour. This standardized, nationally recognized behavior effectively creates two 1:00 AM hours. However, Waterly treats these two 1:00 AM instances as one. This means that once data is logged for 1:00 AM, it will not be reset or duplicated when the clock resets to 1:00 AM again. Data for 2:00 AM and beyond proceeds as usual, without showing a “25-hour day.” Understanding this behavior will allow operations to flow smoothly through this one-day event. Let us examine a real-world example of data entry for the “fall back” event.
Data Entry Challenge During Fall DST
Because the 1:00 AM hour occurs twice, potential operator concern arises where two separate entries at 2:00 AM may overwrite each other. For instance, if an operator logs 12 lbs. of chlorine at 2:00 AM and enters 11.5 lbs. in the repeated 2:00 AM interval, only the second entry is retained. Waterly’s database can differentiate these entries using specific time zone markers (CDT/CST), but the app currently retrieves only the most recent entry.
Reporting and Calculations
Waterly’s reporting tools take DST shifts into account, ensuring reports reflect actual operation times. Certain calculations in the app may show a one-hour adjustment during DST transitions because the app does not visually represent 25-hour days in the fall. Shown below are examples of how each DST event is managed by Waterly in a daily interval report.
---
Conclusion
We hope this article helps you and your team understand how Waterly is designed to manage Daylight Savings Time events. We have taken a standardized, nationally recognized approach to navigate these events with a focus on data integrity. This approach helps keep data handling during DST straightforward for operators and clients, even as time shifts.