In our environment, our Perforce server's clock is set to the US/Eastern timezone. Our QuickBuild server, on the other hand, is set to GMT. When the Perforce plugin asks for the set of changes since the last build, it runs "p4 changes" to get the list and "p4 describe" on each change to get the details. The output of "p4 describe" includes the timestamp of each change, but this timestamp is expressed in terms of the Perforce server's chosen local time.

Our project in QuickBuild is set to poll the Perforce server every 5 minutes and to look for changes. So if I submit a change right now, the QB server will soon notice that change, and start a build. But the "SCM Changes" section of the build indicates that the change was submitted 4 (or 5) hours ago (depending on the current Daylight Savings Time setting).

It's possible for a Perforce client to detect the server's GMT offset. The "p4 info" command produces a long that looks like:

    ... ServerDate 2014/10/30 18:04:19 -0400 EDT

It would be possible for QuickBuild to execute this command before issuing other P4 commands, and to use the offset information returned to reinterpret the output of any Perforce command.

Alternatively, Perforce does support a binary output format. In my experience, it's far easier for code to consume this binary format than to consume the text format. The binary format emits dates as seconds since the Unix epoch, making it easier to avoid timezone issues. The command-line option to the p4 executable to use this mode is "-G".

I had submitted an issue to Perforce asking them for a way to control the timezone of the output of the p4 executable. They indicated that such an issue was already in their system, but they provided no timeline for a fix.