This is a ready-to-use design-review checklist for how a GxP computerized system handles time across more than one time zone: what gets stored, what gets displayed, and how a record created at one site is correctly interpreted at another. Use it during system design, at qualification, or as a periodic control review for a system already live. Replace every <<FILL: ...>> placeholder. A filled specimen follows.
Checklist control
| Field | Entry |
|---|---|
| Checklist number | <<FILL: CHK-ID>> |
| System name and ID | <<FILL>> |
| Sites / time zones in scope | <<FILL>> |
| Reviewed by | <<FILL>> |
| Date | <<FILL>> |
Section 1: Storage strategy
| # | Item | Status (Y / N / NA) | Evidence / location |
|---|---|---|---|
| 1.1 | The system stores every time stamp in UTC, or in local time with an explicit UTC offset captured on the record | <<FILL>> | <<FILL>> |
| 1.2 | The system does not store naive local time (no zone or offset) anywhere a GxP record or audit-trail entry depends on it | <<FILL>> | <<FILL>> |
| 1.3 | The chosen storage strategy is documented in the configuration specification, not left as an unstated default | <<FILL>> | <<FILL>> |
| 1.4 | Where a single fixed reference zone is used for all sites instead of UTC, the choice and its user-confusion risk are documented and accepted | <<FILL>> | <<FILL>> |
Section 2: Display rules
| # | Item | Status | Evidence / location |
|---|---|---|---|
| 2.1 | Every displayed time stamp shows its time zone or offset explicitly (for example “14:32 EDT” or “18:32 UTC”), never a bare number | <<FILL>> | <<FILL>> |
| 2.2 | The rule for which zone a user sees (their own local zone, the originating site’s zone, or a fixed reference zone) is defined and consistent across the application | <<FILL>> | <<FILL>> |
| 2.3 | Printed or exported records (batch records, trial master file documents, reports) state the zone on the page, not only in the live application view | <<FILL>> | <<FILL>> |
Section 3: Cross-site interpretation
| # | Item | Status | Evidence / location |
|---|---|---|---|
| 3.1 | The rule for how a reviewer at Site B interprets a record created at Site A is defined (their own local time, the originating site’s local time, or UTC) | <<FILL>> | <<FILL>> |
| 3.2 | Audit-trail sequencing across sites is confirmed correct because the underlying comparison happens in UTC (or an equivalent unambiguous basis), not on displayed local strings | <<FILL>> | <<FILL>> |
| 3.3 | Procedures and training tell reviewers how to convert or interpret a time stamp created at a different site | <<FILL>> | <<FILL>> |
Section 4: Daylight-saving and time-zone database
| # | Item | Status | Evidence / location |
|---|---|---|---|
| 4.1 | The system uses the IANA time-zone database, or an equivalent maintained source, rather than a hardcoded or manually maintained offset table | <<FILL>> | <<FILL>> |
| 4.2 | Time-zone database updates are handled as a controlled patching activity, not an ad hoc or forgotten task | <<FILL>> | <<FILL>> |
| 4.3 | A record created during the autumn duplicated hour was tested and confirmed to sequence correctly | <<FILL>> | <<FILL>> |
| 4.4 | A record created during the spring skipped hour was tested and confirmed to behave correctly | <<FILL>> | <<FILL>> |
Section 5: Underlying clock controls
| # | Item | Status | Evidence / location |
|---|---|---|---|
| 5.1 | Every host or node contributing time stamps in scope synchronizes to the site’s controlled NTP hierarchy (see the companion time-synchronization SOP and OQ protocol) | <<FILL>> | <<FILL>> |
| 5.2 | Where the system is vendor-hosted or SaaS, the supplier assessment confirms how the vendor synchronizes and what zone their stored stamps use | <<FILL>> | <<FILL>> |
| 5.3 | Where the system spans virtualized or containerized infrastructure, the single-authority rule (one source disciplines the clock, not two fighting) is confirmed and documented | <<FILL>> | <<FILL>> |
Acceptance criteria
- The storage strategy is UTC or local-plus-explicit-offset; naive local time never appears where sequencing or contemporaneousness matters.
- Every display of time carries a visible zone label.
- The cross-site interpretation rule is defined once, applied consistently, and reflected in training.
- Both daylight-saving edge cases (the duplicated autumn hour and the skipped spring hour) have been tested, not assumed correct.
- The time-zone database is current and under change control.
Common inspection findings this checklist prevents
- An audit trail that appears out of sequence across a daylight-saving transition because the system stored naive local time.
- A printed batch record or trial document with a time stamp and no zone label, leaving a reviewer to guess.
- A multi-site investigation where events from two sites cannot be reliably ordered because nobody defined a common basis for comparison.
- A stale time-zone database producing silently wrong local-time conversions after a government changes its daylight-saving rules.
- A vendor-hosted system where nobody can state how the supplier’s infrastructure is time-synchronized.
How to adapt this checklist
- Set the checklist number and the sites/time zones actually in scope for the system under review.
- If the system is single-site and will never hold records from more than one zone, note that basis in Section 1 and treat Sections 2 and 3 as not applicable, with the rationale on file.
- Where a system cannot store UTC or an explicit offset (a legacy or vendor-fixed system), document the gap as a data-integrity risk in the system risk assessment and define a compensating procedural control.
- Pair this checklist with the time-control OQ test script for the executed test evidence behind Section 4’s edge-case rows.
Filled specimen
Illustrative extract for a manufacturing execution system spanning a US East Coast plant and a European quality-review site.
| # | Item | Status | Evidence / location |
|---|---|---|---|
| 1.1 | Stores every time stamp in UTC | Y | Configuration specification CS-MES-018 section 4.2 |
| 2.1 | Every displayed time shows its zone (site-local for operators, with a UTC toggle for QA) | Y | UI specification, screen captures in CS-MES-018 appendix B |
| 3.1 | EU reviewer sees the originating US site’s local time with the zone labeled, by design decision documented in the URS | Y | URS-MES-018, requirement 4.9 |
| 4.3 | Autumn duplicated-hour test executed during OQ, sequence confirmed correct via UTC comparison | Y | OQ-MES-018, test case TC-041, passed 12 Sep 2026 |
| 5.1 | All MES application and database servers sync to site NTP hierarchy TIME-SRV-01/02 | Y | IQ-MES-018 section 3, offsets recorded within 2 seconds |
The daylight-saving test case (TC-041) is the one an inspector is most likely to ask about directly, because it is the fastest way to tell whether a design decision was actually tested or only asserted in a specification document.