Answer
This is deliberate framework design, not a bug — operational reports render entirely server-side, and since reports can also be scheduled (meaning the actual render/execution time can differ from when a user originally requested it), the framework always stamps the report with the server's own execution time rather than any specific client's timezone. A live preview happens to align closely with the ordering time since both occur almost simultaneously, but it's still fundamentally a server-side timestamp. If displaying the client's own local time on the report is genuinely required, the workaround is to explicitly capture and pass the client's local time as a parameter, or as an extra data value in the report's XML, and then reference that specific passed-in value in the report layout instead of relying on the framework's own automatic server-time stamp.