Preserve the time zone after installation

The operating system time zone of the host running P4 Server must be chosen during installation and left unchanged for the entire operational lifetime of that server.

Changing the operating system time zone on a host that already runs P4 Server is a disruptive change. Back up the server, notify affected users, and assess the impact before making the change.

Set the time zone

Set the host operating system time zone to Coordinated Universal Time (UTC) before installing P4 Server. UTC does not observe daylight saving transitions, so timestamps that P4 Server records stay consistent across the life of the installation and across any hosts that participate in replication. Consider UTC the default choice unless a specific operational requirement calls for another time zone.

P4 Server reads the host operating system time zone when it starts and uses it to interpret and record file and metadata timestamps. Because that interpretation is fixed at the time the data is written, changing the operating system time zone later does not retroactively update the timestamps that P4 Server already recorded. The server then interprets previous and new timestamps inconsistently, which is why the time zone is treated as immutable for the operational lifetime of the server.

After an operating system time zone change, files whose type uses timestamp-sensitive keyword expansion, such as the +k filetype modifier, can appear to have changed even though the file content did not change. A p4 verify run against those files can then report a digest mismatch, because the expanded keyword value now reflects a different interpretation of the underlying timestamp. This condition requires both a time-sensitive keyword in the file and a time zone change on the server host, so a site that keeps the installation time zone fixed does not encounter it. For the full list of timestamp-sensitive modifiers, see File type modifiers in the P4 CLI Reference, and for the verification command itself, see p4 verify in the P4 CLI Reference.

Assess the impact of an unavoidable change

If a business requirement makes an operating system time zone change unavoidable, complete the following assessment before proceeding.

  • Confirm that the time zone change is unavoidable and that no alternative, such as adjusting a dependent process instead of the server, resolves the underlying requirement.
  • Identify every host in the installation, including replicas, edge servers, standbys, and the commit server, and plan to change the time zone on every host together.
  • Schedule a maintenance window and notify all affected users in advance.
  • Back up the server, including the versioned files, database, and configuration, before making the change.
  • Run p4 verify before the change to establish a known-good baseline, and run it again after the change to identify any digest mismatches that the time zone change introduced. The change does not affect shelved files that contain time-sensitive keywords, so running p4 verify -S against them does not report a time zone discrepancy.
  • Create an inventory of files with timestamp-sensitive keyword expansion, such as the +k filetype modifier, so mismatches reported after the change can be evaluated against a known cause.
  • Review scheduled tasks, triggers, and journal rotation schedules that depend on local time, and update them to account for the new time zone.
  • Review license expiration handling and any integration or reporting tool that stores or displays P4 Server timestamps, and confirm that each one continues to interpret those timestamps correctly after the change.
  • Rotate the journal and the server logs as part of the change, so the time zone discontinuity falls at the start of a new file instead of partway through an existing one.
  • Document the change, including the date, the previous and new time zones, the verification results, and the journal number, for future reference by support and administration staff.

Consider secondary operational consequences

An operating system time zone change can also affect the following areas of an existing installation.

  • Audit and structured logs, which show a discontinuity at the point of the change. This can complicate log-based troubleshooting and reporting that spans the change.
  • Replication and journal timestamps recorded before and after the change. These reflect different time zone interpretations, which can complicate historical reporting.
  • Support cases and change history that reference timestamps recorded before the change, which require the previous time zone to interpret correctly.
Each P4V user can choose whether P4V shows timestamps in the local time zone of the machine running P4V or in the server's time zone (P4V > Edit > Preferences > Display). This per-user display preference only changes how existing timestamps are shown and does not affect how P4 Server stores or interprets timestamps.