When a historian records a timestamp, it has to decide what time zone that number represents, and the choice has real consequences. Store local wall-clock time and you inherit every quirk of the local calendar, including the twice-yearly chaos of daylight saving transitions. Store the universal standard, UTC, and every timestamp is unambiguous, at the small cost of converting for display. This guide makes the case for storing UTC and converting to local only when a human looks at it, explains the duplicate and missing hour that daylight saving creates in local-time storage, and covers how multi-timezone cloud SCADA keeps sites reconciled.
UTC vs Local Time Storage in one line: A historian should store timestamps in UTC, the single global time standard that never shifts for daylight saving, and convert to local time only for display. Storing local time creates ambiguity twice a year at daylight saving transitions, when one wall-clock hour repeats and another is skipped, whereas UTC timestamps are always unique, ordered, and directly comparable across sites and time zones.
UTC is a single, global time standard that ticks forward uniformly and never jumps for daylight saving or regional rules. When a historian stores every timestamp in UTC, each value carries an absolute, unambiguous instant that means the same thing everywhere on Earth. Two readings can always be compared, ordered, and subtracted without first asking what time zone they were in or what the local rules were on that date. That property, that a stored timestamp is a globally unique moment, is the foundation of a trustworthy time series.
Storing local wall-clock time throws that property away. Local time is UTC bent by a time-zone offset and by daylight saving rules that change with the season and occasionally with legislation. A timestamp like a particular hour and minute on a particular date is not, by itself, a unique instant in a place that observes daylight saving, because that same wall-clock reading can occur twice a year or not at all. The historian ends up storing numbers that require external context to interpret, and that context is exactly the part that shifts and gets forgotten.
The clean architecture is to store UTC and convert to local only at the moment a human looks at the data. The database, the calculations, the trend alignment, and the cross-site comparisons all operate on unambiguous UTC, while the display layer applies the viewer's chosen time zone at render time so operators still see familiar local times. This separates the stable question of when something happened from the presentation question of how to show it, and it means the same underlying record can be shown correctly to a user in any time zone without ever being altered.
Daylight saving is where local-time storage breaks in a way that is easy to demonstrate. When clocks spring forward in the spring, a whole hour of local wall-clock time simply never occurs; the clock jumps straight from one hour to the next. A historian trying to store local time has an hour that does not exist on its calendar, so any event nominally in that hour has no valid local timestamp to attach to. Conversely, when clocks fall back in the autumn, an hour of local wall-clock time happens twice, so a single local timestamp is genuinely ambiguous: it could refer to either of two distinct instants an hour apart.
That ambiguous, repeated hour is the more insidious of the two. In a local-time historian, two readings taken sixty minutes apart during the fall-back transition can land on the same local timestamp, making it impossible to tell from the stored value alone which came first. Ordering silently breaks, trends can fold back on themselves, and sequence-of-events analysis loses its footing for that hour every single year. None of this happens in UTC, because UTC never repeats or skips an hour; the transition is purely a display concern layered on top of a timeline that stayed continuous underneath.
This is why standardized, unambiguous representations matter. The ISO 8601 format writes a timestamp as a specific date and time together with an explicit offset from UTC, so the string itself pins down an exact instant with no guessing. An epoch representation goes further and stores time as a plain count of seconds from a fixed reference point, a single number with no time zone attached at all, which is inherently monotonic and unambiguous. Whether a system uses ISO 8601 with an explicit offset or a raw epoch count, the point is the same: the stored value should identify one and only one instant, which local wall-clock time cannot guarantee.
A cloud SCADA system almost always spans time zones. A single operator may watch wellpads, plants, and pump stations scattered across several states or countries, each in its own local zone with its own daylight saving calendar. If each site stored its data in its own local time, comparing them would require untangling a different set of offsets and transition dates for every site, and any event that fell in an ambiguous or skipped hour at one location would be a special case. That path leads to a tangle of edge cases that surfaces precisely twice a year.
Storing everything in UTC collapses that complexity. Every site's data lands on one common, absolute timeline regardless of where the site physically sits, so an event at a location in one zone can be lined up against an event at a location in another zone directly, with no offset arithmetic and no daylight saving special cases. The moment of comparison, the shared UTC instant, is the same for all of them. Time zones re-enter the picture only at the edges, when the raw data comes in from a device and when a person views it.
For a platform like Merobix, that means capturing each reading as an absolute UTC instant on the way in and then letting each viewer see it in whatever local time makes sense to them on the way out. An operator in one region and a manager in another can look at the identical event and each see it in their own familiar clock time, while underneath they are looking at exactly the same UTC moment. Storing UTC and converting for display is what lets a multi-site, multi-timezone monitoring system stay simple, correct, and free of the annual daylight saving surprises that local-time storage guarantees.
Because local wall-clock time is not a unique instant in any place that observes daylight saving. Twice a year a local hour either repeats or is skipped, so a stored local timestamp can be ambiguous or invalid, which breaks ordering and comparison. Storing UTC keeps every timestamp unique and comparable, and the system can still show operators their familiar local time by converting only at display.
ISO 8601 is a human-readable text format that writes the date and time together with an explicit offset from UTC, so the string itself identifies an exact instant. An epoch timestamp stores time as a single count of seconds from a fixed reference point, with no time zone attached at all. Both pin down one unambiguous moment; ISO 8601 is easier to read, while epoch is compact and naturally monotonic, and either is a sound way to store time as long as it is anchored to UTC.
It puts every site's data on one common absolute timeline no matter what time zone each site sits in. That lets an event at one location be compared directly with an event at another without any offset arithmetic or daylight saving special cases, because they share the same UTC instant. Time zones only matter at the edges, when data arrives and when a person views it, which each viewer can see in their own local time.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.