Device Timestamps at a Daylight-Saving Change: Test the Repeated Hour

Store each device event as UTC or as local time with its actual numeric UTC offset. Then test the repeated hour through storage, display, sorting, interval calculations, and export. In US locations observing daylight saving time, November 1, 2026 repeats the 1 a.m. hour. Two entries labelled 01:23 need an offset or other reliable evidence to identify their order. The six-event dataset below is an editorial verification proposal, not an FDA-prescribed test. NIST's 2026 transition rules.

What Repeats on November 1, 2026

At 2 a.m., participating US clocks return to 1 a.m. A local-only record can therefore reuse a timestamp or appear to move backward. For example, an event at 01:45 during the first hour occurs before one at 01:07 during the second hour. Sorting those wall-clock labels reverses their order. This is a representation problem: an accurate underlying clock cannot restore an offset discarded when the record was written.

The failure has been observed in a working laboratory. Ehlers and colleagues' 2018 study of one academic medical center found four inconsistent timestamp combinations at the 2017 autumn change. One Type and Screen result appeared earlier than specimen receipt, blocking transmission through an interface and requiring manual posting to the electronic health record. The authors described overall impact as low; blood products issued around the change were released without incident. This is evidence of a record and interface problem, not a device-wide injury rate. Impact of Daylight Saving Time on the Clinical Laboratory.

The study also describes older analyzer computers with obsolete US daylight-saving rules and differences between automatic and manual adjustment. Separately, Medscape's March 5, 2007 coverage reported an FDA MedWatch warning about devices using the wrong transition dates after the US rule change. Its listed potential consequences included mistimed or missing doses and incorrect records. That dated report supplies historical context, not evidence that today's devices commonly cause those outcomes. Medscape's historical report.

Where Timestamps Live in a Device

Begin with an inventory of the records and calculations that depend on time. An event log, an operator audit trail, a scheduled action, and a service record can share a display clock while using different storage paths. The proposed review below separates those paths so a correct screen does not conceal an ambiguous database or export.

• Event and alarm history: identify the field that represents occurrence time, the ordering key, and any separate receipt time assigned by another system.

• Therapy or diagnostic records: identify interval calculations and scheduled actions that use wall-clock values. Establish their intended behavior from the device requirements rather than assuming the log format describes the controller's timer.

• Operator audit trails and signatures: identify which entries are regulated electronic records and which date and time accompany a signed action.

• Service and investigation records: identify the timezone configuration and software version needed to interpret records after the device is returned or updated.

For manufacturers subject to Part 820, the QMSR incorporates ISO 13485:2016 through section 820.7. Section 820.10(c) applies its clause 7.3 design-and-development requirements to class II, class III, and specified class I devices, including devices automated with computer software. Section 820.35 specifies additional complaint and service record information, including relevant dates. These provisions establish the regulatory setting; they do not specify a UTC format, counter width, timestamp resolution, or named daylight-saving test. Current 21 CFR Part 820.

Assess Part 11 applicability for each record under section 11.1. Being electronic does not by itself make every device log subject to Part 11. For applicable closed systems, section 11.10(e) requires timestamped audit trails for record-changing operator actions without obscuring prior information; section 11.10(f) addresses permitted operational sequencing, as appropriate. Section 11.50(a)(2) requires the date and time of an electronic signature. Sorting a history correctly and enforcing permitted workflow steps are related engineering concerns, but are separate controls. 21 CFR Part 11.

FDA's June 2023 device-software submission guidance recommends documentation for premarket review; its January 2002 General Principles of Software Validation addresses software validation. Neither prescribes this repeated-hour dataset. They are guidance, not a separate legal mandate for these exact cases. Use the current QMSR for regulatory requirements when consulting older validation guidance. FDA's device-software submission guidance. General Principles of Software Validation.

For the wider process, see the design verification and validation guide and the Part 11 electronic records guide. This article focuses on specifying and verifying device timestamps; sponsor trial-system validation is covered in the EDC validation guide.

Specify Storage, Ordering, and Local Display Separately

RFC 3339 represents an instant with a stated relationship to Coordinated Universal Time (UTC), using Z or a numeric offset. For completed events, an offset-bearing value can distinguish the two occurrences of a local hour. A zone identifier is also useful for understanding the display context, but a local label plus America/Chicago alone still needs a choice between the two occurrences of an ambiguous time. RFC 3339.

Do not sort mixed-offset timestamps as plain strings. RFC 3339 section 5.1 limits its string-ordering property to matching timezone representations and fractional-second precision. Parse offsets and compare the resulting UTC instants. Standardized UTC strings in the same format can sort correctly as text; values ending in -05:00 and -06:00 do not share that guarantee. The standard's status page notes its update by RFC 9557; the examples here use the base RFC 3339 representation. RFC 3339 section 5.1.

NIST explains that NTP contains no daylight-saving information and that local corrections depend on the operating system. Synchronization and record representation therefore need separate checks. IANA documents government-controlled timezone rules, sometimes changed with little notice. For the proposed protocol, record the zone configuration and rule-data version used by the build, and define how maintained rules reach deployed devices. The laboratory's obsolete-rule examples show why a correct transition date matters as well as a correct offset. NIST's explanation of NTP and local corrections. IANA's timezone-data reference.

flowchart LR
  E["Captured event"] --> S["UTC instant or local time with actual offset"]
  S --> O["Parse instant before sorting and subtraction"]
  S --> U["Local display with visible offset"]
  Z["Configured zone and maintained rules"] --> U
  S --> X["Export preserving instant and event identity"]

If a sequence number supplements UTC, define its scope. An incrementing event counter orders one event stream; it does not measure elapsed seconds or automatically order events from different devices. Document restart, reset, and wrap behavior, and use a stream or run identifier when numbers can recur. Likewise, a UTC label does not guarantee that a clock never moves after correction. The dataset isolates a daylight-saving change; clock corrections, power loss, and distributed ordering need their own product-specific coverage.

The Repeated-Hour Dataset: Six Events, Four Designs

This synthetic dataset is an editorial test-design proposal, not observed device performance or an industry-standard protocol. It uses the US fall-back rule and a configured America/Chicago display zone. The first hour has offset -05:00 and the repeated hour has offset -06:00. All events occur on November 1, 2026; whole-minute values make the arithmetic easy to check. Event labels are generic and do not prescribe any therapy or alarm response. US transition basis. Numeric-offset semantics.

• Design A stores local date and time without an offset. Its displayed labels can look familiar, but the record cannot identify the occurrence of the repeated hour.

• Design B stores RFC 3339 local time with the actual numeric offset. Its comparator must parse the offset rather than compare the raw strings.

• Design C stores a UTC timestamp and a separate zone field set to America/Chicago. The zone field supplies display context; it is not appended to the RFC 3339 timestamp as part of its syntax.

• Design D stores UTC plus an incrementing event sequence within this simulated run. It uses the same configured display zone and adds an ordering key for this single stream.

The next table gives the expected stored values. For C, retain zone=America/Chicago as a separate field for every row. For D, retain stream=simulated-run-1 alongside the listed sequence. These are schema examples for comparison, not mandated fields or claims about a particular device.

Acceptance Criteria for Storage, Display, and Export

Run the proposed cases in a controlled software test environment. Establish a reference independent of the local display, inject the six events in UTC order, and inspect the persisted records after retrieval. Capture the UI and pass the same records through the actual export and receiving parser. A timestamp that is correct before serialization can lose its offset later, so inspecting only the writer is insufficient.

For this bounded test, require the recovered order E1, E2, E3, E4, E5, E6. Design A sorts as E1, E4, the tied E2/E5 pair, E3, E6. Design B also fails if sorted as raw text: even though its offsets distinguish the instants, its 01:07 value sorts before the first hour's 01:23 value. B passes this ordering case only with an offset-aware comparator. C and D pass the constructed case when their UTC values and stream ordering are processed as specified.

For display, require users reviewing chronology to distinguish E2's 01:23 -05:00 from E5's 01:23 -06:00. The wall-clock hour may repeat while the event list remains in true order. Preserve the underlying instant when changing display zones. A visible offset is the proposal used here; a different interface needs an equally testable way to distinguish the occurrences.

For export, compare the parsed instant and event identity before and after the round trip. If B is converted to UTC, the UTC values must match the reference table. If it remains local, retain each numeric offset. For C, retain the zone when reproducing the original display is a requirement. For D, retain the stream and sequence when they are part of the ordering requirement. Intentionally strip the offset in a negative test: the receiver should report ambiguity or fail the criterion rather than silently assign one occurrence of the hour.

Check Interval Math and Rule Maintenance

The 85-minute case is explicit: E1 is 05:58 UTC and E5 is 07:23 UTC. Subtracting local labels gives 25 minutes. Adding an extra DST hour after already subtracting UTC instants gives 145 minutes, a different implementation error. These are computed expectations for the synthetic inputs, not measured delays. Evaluate every interval-dependent feature in scope against its own requirements; a sequence difference cannot substitute for this elapsed-time calculation.

Data Innovations' Instrument Manager bulletin provides a concrete dependency example. It warns that clock adjustment can affect time-difference features, including turnaround times, Hold Until Complete logic, trickle-feed workflows, and custom timers. This is product-specific vendor evidence, not proof that another device implements the same functions or failures. It supports reviewing downstream calculations as well as the stored event list. Instrument Manager daylight-saving guidance.

Add a rule-maintenance check within the same evidence section: record the deployed rule version, confirm the transition date and offset for the configured market, and verify that a rule update changes intended rendering without rewriting historical instants. Include a stale-rule negative case if relevant to the supported software environment. The laboratory study documented obsolete rules; IANA explains the changing rule dependency. Neither source supplies a universal update interval for medical devices, so the maintenance procedure must define its own review and deployment process. Laboratory evidence. IANA's rule-data reference.

Spring Forward and Markets Without DST

NIST gives March 8, 2026 as the US spring transition: participating clocks move from 2 a.m. to 3 a.m. A proposed complementary test is a scheduled action at local 02:30, a time that does not occur that day. Specify the intended handling before testing. Skipping, deferring, or otherwise handling the action depends on its purpose and risk; the calendar rule does not decide that behavior. US spring-transition rule.

A second synthetic check spans 01:50 -06:00 to 03:10 -05:00: the UTC instants are 07:50 and 08:10, only 20 minutes apart. Local subtraction gives 80 minutes. Use that calculation to test a relevant interval function, without asserting that any particular therapy controller or alarm will fail. For repeated-hour scheduling, also specify whether a local-time action may run once or twice. A correct event-history format alone does not settle scheduling requirements.

Scope the matrix to supported markets and configurations. NIST identifies US locations that do not observe DST, including Hawaii and most of Arizona. A no-DST configuration needs a negative test for an unintended seasonal shift. Other countries can use different transition dates or rules; use maintained, verified deployment rules rather than reusing the US November case globally. This article does not establish non-US transition dates or legal arrangements. IANA's jurisdiction-dependent rule reference. NIST's US exceptions.

Investigating Legacy Local-Only Records

Start a reconstruction by preserving the original data and recording the device's configured zone, rule version if available, and automatic or manual adjustment behavior. A timezone history can identify candidate UTC instants. For an entry inside a repeated hour, however, knowing the zone does not select between those candidates. Adding today's offset to every old record would create apparent precision without evidence.

• Look for independent, offset-bearing or UTC records of the same events. Distinguish event occurrence from server receipt: transmission delay can limit what a receipt timestamp proves.

• Check any recorded sequence field and its documented scope, including resets and missing records. A counter added in a later software version cannot resolve an older record that never contained it.

• Document which orderings are supported, which remain possible, and what evidence is absent. Keep reconstruction notes distinct from the original records so uncertainty remains visible.

The proposal is an evidence-preservation approach, not a guarantee of reconstruction. If E2 and E5 survive only as identical local strings and no other information distinguishes them, their instants cannot be recovered uniquely. Report that limitation in the investigation rather than manufacture a complete chronology. The laboratory study's result-before-receipt example illustrates why the displayed labels alone may be misleading.

Document the Protocol in Design Records and Submissions

Connect the test to a requirement and a plausible failure mode. A useful proposed requirement is: 'The event history shall preserve the occurrence order and instant of each event across a configured daylight-saving transition. Local display and export shall retain enough information to distinguish repeated-hour entries.' Select timestamp precision, counter design, and supported zones from product needs; this example does not establish universal millisecond resolution or a 32-bit counter requirement.

1. Record the rationale: which event history, interval function, or export would become ambiguous, and why that matters to intended use or record review.

2. Record the setup: software build, timezone configuration, rule version, reference time source, injection method, storage path, export format, and receiving parser.

3. Record expected results before execution: recovered event order, the interval values above, distinguishable local displays, and preserved instants after export.

4. Record actual results and discrepancies: preserve the input dataset, retrieved records, output artifacts, and the disposition of each failed criterion. A six-row example passing is evidence for its cases, not proof of every clock behavior.

Place the resulting evidence in the applicable design and software verification records under the manufacturer's quality system. For a premarket submission, assess the documentation appropriate to the device and FDA's software guidance, and connect any submitted test evidence to the requirement and risk it addresses. Do not claim FDA requires this specific November 2026 protocol or that a passing result alone establishes regulatory compliance. FDA's software documentation recommendations.

Broader lifecycle documentation is discussed in the IEC 62304 implementation guide. The decision here remains narrow: preserve the instant first, verify repeated-hour behavior across every relevant representation, and state the test's limits alongside its results.