= Treat the P4 Server Timezone as Immutable After Initial Installation
:author: Perforce Professional Services
:revdate: 2026-08-14
:toc: left
:toclevels: 3
:sectnums:
:source-highlighter: highlight.js
== Executive Summary
The operating-system timezone of a P4 Server must be selected during initial installation and treated as immutable for the operational lifetime of that server instance.
Changing the timezone does not alter the stored sequence of changelists or the underlying instant represented by an epoch timestamp. It does, however, change the timezone context in which the server processes time. The change has permanent repository-visible consequences:
. For files that use RCS keyword expansion, such as `text+k` or the historical `ktext` alias, changing the timezone changes date-bearing keyword expansion. This changes the byte stream used for checksum validation and causes stored digests to disagree with newly calculated digests. At scale, the result can be widespread verification failures, merge failures, and messages warning that archive content might have been tampered with.
. Changing the timezone changes the local-time representation of existing history and changes the meaning of date-based revision specifications. The same date/time expression can identify a different point in repository history after the change.
. Changing the timezone complicates comparison with previously recorded audit evidence, reports, procedures, and external systems that retain the original local-time convention.
. Changing the timezone complicates log correlation, particularly when topology members or related systems do not change at precisely the same operational boundary.
These effects are not hypothetical risks. They follow directly from changing the timezone context used by an established P4 Server. The severity depends heavily on repository content and operational practices. In particular, an installation containing a large population of `+k` revisions can experience severe and prolonged disruption.
[IMPORTANT]
====
Do not change the timezone of a P4 Server after initial installation.
Treat the server timezone as an immutable part of the server's persistent operational identity. If an exceptional business or technical requirement makes a change unavoidable, handle it as a high-risk P4 data migration, not as routine operating-system maintenance.
====
== Scope
This guidance applies to the timezone configured on the operating system that hosts a P4 Server, including a commit server, edge server, replica, or standalone server.
This guidance concerns changing the timezone, such as changing a host from Pacific Time to UTC. It is distinct from maintaining clock accuracy within the established timezone. Accurate clock synchronization remains necessary, particularly in a distributed topology. Clock synchronization corrects clock drift; it must not be implemented by redefining the server's established timezone.
== The Timezone Is Part of the Server's Persistent Operational Context
P4 Server records time values as seconds since the Unix epoch. Changing the operating-system timezone therefore does not rewrite each stored timestamp and does not move the underlying event to a different instant.
The timezone is nevertheless operationally significant. P4 Server uses its timezone when converting stored time values to human-readable local dates and times and when interpreting local date/time input. Changing the timezone changes the frame of reference applied to existing history and future date-based requests.
The distinction is precise:
* The instant represented by a stored epoch value remains unchanged.
* The displayed local date and time changes.
* A date/time supplied without an explicit timezone is interpreted in the server's current timezone.
* A date-based revision specification therefore identifies a different historical boundary when the timezone changes.
* Date-bearing RCS keywords expand using the changed timezone context, which changes checksum input for affected `+k` revisions.
The repository chronology is not reordered, but the established local-time meaning of that chronology is permanently changed.
== Primary Risk: RCS Keyword Expansion and `+k` File Integrity Checks
=== Why this is the highest-impact consequence
Files with the `+k` modifier use RCS keyword expansion. Examples include the modern `text+k` type and the historical `ktext` alias. Supported keyword markers embedded in file content are expanded to revision-specific values when P4 materializes or processes the file.
Some expanded keywords contain a date or date/time. Changing the server timezone changes those expanded values. Because a checksum is calculated from bytes rather than from the abstract meaning of the content, a changed date/time expansion changes the checksum input.
Conceptually, the difference can look like this:
[source,text]
----
Before timezone change:
$DateTime: 2026/08/14 10:30:00 $
After timezone change:
$DateTime: 2026/08/14 17:30:00 $
----
The exact keyword value and format depend on the keyword and revision metadata. The deterministic consequence is that a changed date-bearing expansion produces a different byte sequence.
=== Why verification reports `BAD!`
`p4 verify` validates archived revisions against stored digest information. For a revision using RCS keyword expansion, checksum processing accounts for the keyword-expanded form according to the filetype semantics.
After the server timezone changes, a date-bearing keyword expands differently from the way it expanded when the original digest was established. The recomputed checksum differs from the stored checksum, and `p4 verify` reports the affected revision as `BAD!`.
In this specific and established scenario, the mismatch is caused by the timezone change. The message does not, by itself, demonstrate that archive bytes were maliciously or accidentally modified. Nevertheless, the message is operationally serious because the same integrity checks protect against actual archive damage. Administrators and users cannot simply disregard it.
[WARNING]
====
A timezone-induced checksum mismatch is not merely a cosmetic verification warning. Operations that depend on successful content validation, including merge-related processing, can fail with messages indicating that files might have been tampered with.
In a repository containing hundreds of thousands of `+k` revisions, identifying and validating the affected population can require an extensive verification effort. Normal workflows can remain impaired until the affected revisions are correctly identified, their archive integrity is established, and digest metadata is remediated under a controlled plan.
====
=== Why the impact scales badly
The operational cost is proportional not only to the number of depot files, but to the number of affected file revisions. A repository can contain a very large historical population of `+k` revisions even if relatively few such files remain active today.
The consequences can include:
* Large numbers of alarming `BAD!` verification results.
* Merge and related workflow failures caused by content-integrity checks.
* Extended verification runs needed to identify the affected revision population.
* Difficulty distinguishing expected timezone-induced mismatches from genuine archive corruption.
* Pressure to replace stored digests before the underlying cause and archive integrity have been established.
* Prolonged operational disruption while administrators investigate messages that reasonably appear to indicate tampering.
The ambiguity between an expected timezone effect and actual tampering is itself harmful. The integrity warning must remain meaningful, so the affected revisions require disciplined investigation and remediation rather than blanket suppression.
=== Digest recalculation is remediation, not prevention
Recalculating a digest can align stored verification metadata with content processed under the new timezone. It does not undo the timezone change, restore the former expansion, restore the former meaning of local date/time queries, or make the migration transparent.
Before replacing stored digests, an administrator must establish that:
* The mismatch belongs to the understood timezone-sensitive `+k` population.
* The archive content is the intended revision content and has not been damaged or altered.
* Current checkpoints, journals, archive backups, and recovery materials are available.
* The new timezone is accepted as the permanent timezone for the server and its topology.
* All affected workflows and integrations have been evaluated.
A digest must not be recalculated merely to eliminate an unexplained verification error.
Perforce documents the relationship among timezone changes, `ktext` or `text+k` files, `p4 verify`, and digest recalculation in link:https://portal.perforce.com/s/article/2476[Moving a P4 Server to a different timezone].
== Permanent Change to Historical Time Interpretation
=== Existing history is displayed in the new timezone
Suppose a changelist was submitted while a server operated in Pacific Time. After changing the server to UTC, the underlying epoch timestamp still identifies the same instant, but the event is displayed using UTC. The reported wall-clock time changes and, near a day boundary, the reported calendar date changes.
It is inaccurate to say that the stored history is numerically shifted or corrupted. The precise statement is:
[quote]
____
Changing the P4 Server timezone permanently changes the local-time representation and interpretation of existing history. Stored events remain at the same instants, but they are reported using the new timezone, and local date/time expressions no longer identify the same historical boundaries that they identified before the change.
____
The apparent difference is not necessarily a single fixed number of hours throughout the year. If the old timezone observes daylight-saving time, its UTC offset differs by date. Changing from such a regional timezone to UTC therefore changes historical wall-clock times by one offset for part of the year and another offset for the remainder.
This loss of continuity affects the authenticity and interpretation of historical local-time records. Previously captured reports, audit evidence, screenshots, support records, and procedural references can show different local timestamps from current output for the same repository events.
=== Date-based revision specifications change meaning
P4 revision specifications can use a date and time to identify repository state. For example:
[source,console]
----
p4 sync //depot/project/...@2026/08/14:10:30:00
----
P4 Server interprets that date/time in the server's timezone. Changing the server timezone changes the instant denoted by the expression. The unchanged command can therefore select a different revision or set of revisions after the timezone change.
This behavior affects every workflow that relies on a server-interpreted local date/time as a historical boundary. When a procedure must identify an invariant repository state, use a stable identifier such as a numbered changelist rather than a local date/time expression.
The Perforce KB article link:https://portal.perforce.com/s/article/2476[Moving a P4 Server to a different timezone] demonstrates that an unchanged date-based revision specification can select a different revision after the server timezone changes.
== Distributed and Replicated Topologies
Servers participating in the same P4 topology must use a consistent timezone configuration. The P4 Server Administration Guide lists timezone among the characteristics in which a replica must match its target server.
A timezone change on an established commit server, edge server, or replica is therefore a topology concern, not an isolated host adjustment. Consistent configuration is necessary for coherent timestamp interpretation, keyword processing, verification analysis, and operational support.
The required standard is:
[quote]
____
Select one timezone during initial deployment, configure it consistently across the complete P4 topology, maintain accurate clock synchronization, and do not change that timezone during the operational lifetime of the environment.
____
UTC is often a sensible choice for a new globally distributed deployment because it avoids daylight-saving transitions. That is an installation-time design decision. The benefits of UTC do not justify converting an established server from its existing timezone after repository history and `+k` digests have been created in that context.
== Secondary Operational Consequences
The `+k` integrity impact and the permanent change to historical time interpretation are the primary reasons to prohibit a timezone change. Additional consequences reinforce the same policy:
* Existing reports, audit records, screenshots, procedures, and support evidence retain timestamps expressed in the former timezone, while new server output presents the same events in the new timezone.
* External systems can continue to interpret or present timestamps according to the former convention.
* Time-based automation and integrations must be reviewed for changed local-time boundaries.
* Log correlation becomes more difficult across the transition, particularly if related systems or topology members do not change at the same operational boundary.
These concerns are generally more manageable than a large `+k` population, but they add cost, ambiguity, and risk to a change that should not occur in an established environment.
== Timezone Stability Versus Clock Synchronization
Timezone configuration and clock synchronization solve different problems:
Timezone:: Defines how an instant is represented as a local date and time and how local date/time input is interpreted.
Clock synchronization:: Keeps the host clock aligned with an authoritative time source and limits drift.
Administrators should maintain accurate time through a supported operating-system synchronization service. They must not change the timezone, or manually add or remove hours from the clock, as a substitute for correcting clock synchronization.
Enabling, disabling, or reconfiguring a synchronization service does not inherently require a timezone change. If a host clock is significantly inaccurate, correcting it is itself an operational event that must be planned and monitored, but the established timezone should remain unchanged.
== Required Operational Policy
The following language is suitable for an operational standard:
[quote]
____
The operating-system timezone of a P4 Server is an installation-time setting and shall be treated as immutable after the server enters service. The timezone shall not be changed as part of host relocation, data-center migration, cloud migration, operating-system maintenance, or a preference for UTC. All servers in a P4 topology shall use a consistent timezone and maintain accurate clock synchronization.
An unavoidable post-installation timezone change shall be classified as a high-risk P4 data migration. It requires explicit P4 administrative review, a documented impact assessment, complete recovery protections, a maintenance and validation plan, an inventory of `+k` revisions, verification of affected archives, and controlled remediation of digest metadata. Date-based repository operations, historical reporting, replicas, integrations, and external audit dependencies shall also be evaluated.
____
== If a Timezone Change Is Unavoidable
There is no zero-impact procedure for changing the timezone of an established P4 Server. A required change must be handled as a controlled migration whose purpose is to manage known consequences, not as a routine setting change.
The exact procedure must be tailored to the topology, P4 Server version, operating system, number of `+k` revisions, backup design, integrations, and business requirements. At minimum, the migration plan must address the following areas:
. Record the old timezone, its historical UTC-offset behavior, and the intended new timezone.
. Inventory all P4 Server processes and topology members that must remain consistent.
. Inventory `+k` revisions and estimate the verification and remediation scope before changing the timezone.
. Establish and retain a verification baseline.
. Identify merge workflows and other operations that depend on content-integrity validation.
. Identify procedures and integrations that use date-based revision specifications.
. Preserve current checkpoints, journals, archive backups, configuration, and verification evidence in accordance with the site's recovery procedures.
. Define how genuine archive damage will be distinguished from timezone-induced `+k` mismatches.
. Apply the timezone change consistently to the affected topology under a controlled maintenance boundary.
. Validate server time, synchronization status, replication, integrations, historical display, and date-based query behavior.
. Run targeted verification for known `+k` content and broader verification as required by the validation plan.
. Investigate every mismatch before changing stored digest metadata.
. Recalculate stored digests only after the cause and integrity of the affected revisions have been established.
. Document the permanent change for administrators, auditors, support personnel, disaster recovery procedures, and future migrations.
This list is an impact-assessment framework, not a substitute for a site-specific runbook.
== Customer-Facing Explanation for an Observed `+k` Incident
The following statement can be reused in customer communications:
[quote]
____
The verification and merge failures observed for files using RCS keyword expansion (`+k` or `ktext`) are a direct consequence of changing the P4 Server timezone. They do not, by themselves, demonstrate malicious tampering or storage corruption.
P4 stores timestamps as epoch values, but the server timezone participates in date-bearing RCS keyword expansion. Changing the timezone changes the expanded byte stream used during checksum validation. The newly calculated checksum therefore differs from the digest established under the original timezone, and integrity-dependent operations can report that the file might have been tampered with or can refuse to continue.
The timezone change also permanently changes the local-time representation of existing repository history and changes the meaning of date-based revision specifications. Although the underlying sequence and instant of repository events remain intact, the same local date/time expression can identify a different repository boundary after the change.
For these reasons, the P4 Server timezone is an installation-time decision and must be treated as immutable after the server enters service.
____
== Conclusions
A P4 Server timezone is not a cosmetic display preference. It is an input to date-bearing RCS keyword expansion and checksum validation, and it defines how the server presents and interprets historical time.
For repositories with `+k` history, changing the timezone can cause widespread integrity-check and merge failures across the complete population of affected revisions. Independently of `+k` usage, the change permanently alters local-time reporting and the meaning of local date/time queries. Secondary effects include audit discontinuity, integration changes, and log-correlation difficulty.
The administrative rule is therefore unequivocal:
[IMPORTANT]
====
Do not change the timezone of a P4 Server after initial installation.
Treat the P4 Server timezone as immutable for the lifetime of the server environment.
====
For a new installation, choose the timezone deliberately, configure it consistently throughout the P4 topology, and maintain accurate clock synchronization. For an established installation, preserve the existing timezone through host replacements, migrations, upgrades, and changes in physical location.
== References
* link:https://portal.perforce.com/s/article/2476[Perforce KB: Moving a P4 Server to a different timezone]
* link:https://help.perforce.com/helix-core/server-apps/p4sag/2025.2/Content/P4SAG/replication.requirements.html[P4 Server Administration Documentation: Requirements for replication systems]
* link:https://help.perforce.com/helix-core/server-apps/cmdref/current/Content/CmdRef/file.types.synopsis.modifiers.html[P4 CLI Reference: File type modifiers]
* link:https://help.perforce.com/helix-core/server-apps/cmdref/current/Content/CmdRef/filespecs.html[P4 CLI Reference: File specifications]
* link:https://help.perforce.com/helix-core/server-apps/cmdref/current/Content/CmdRef/p4_verify.html[P4 CLI Reference: p4 verify]