> For the complete documentation index, see [llms.txt](https://docs.openiam.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.openiam.com/administration-guide/operations/timestamps-off-by-a-fixed-offset.md). # Timestamps off by a fixed offset Tell the three timezone knobs apart when every audit and log timestamp is out by a whole number of hours, and hand the right one to the deployment owner. ## What this is, and when you need it The symptom is unmistakable once you know to look for it: **audit and log timestamps are exactly one hour earlier than wall-clock time** — or exactly two, or exactly five, whatever your zone's offset from UTC happens to be. It is never a few seconds out and never drifts, which is what distinguishes it from a clock-synchronisation problem. A fixed whole-hour (or half-hour) shift is always a timezone-interpretation problem, and there are **three separate knobs** that can produce it. Confusing them is the usual reason a fix does not take. {% hint style="info" %} **If the timestamps are not merely shifted but malformed, this is the wrong page.** A stored epoch number where an ISO 8601 string belongs is a data-format problem rather than a timezone one, and it is fixed by converting the documents — see [Audit document timestamp issue](/troubleshooting/logs-and-diagnostics/audit-doc-timestamp.md). {% endhint %} ## At a glance | | | | ------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **You will end up with** | Two readings of the same event — one on screen, one in a service log — that between them name which of the three knobs the shift comes from. Nothing is changed; the remedy is the deployment owner's | | **Where** | **Administration → Log Viewer**, `/webconsole/viewAuditLog`, and the service log for the same event | | **You need first** | One event you can time by hand — a sign-in is easiest — your own wall clock, and the ability to ask for a service log covering that minute | | **Takes** | 10–15 minutes | | **Reversible** | Yes — you change nothing, so there is nothing to roll back; what you cannot take back is acting on the wrong knob, and knobs 1 and 2 need the services restarted together | ## Before you begin Establish that the shift is fixed. A whole-hour or half-hour offset that never drifts is a timezone question; seconds of drift that grow are a clock-synchronisation question and nothing on this page applies to them. ## Run the three-way comparison The one diagnostic that separates the knobs is a comparison, and you can make it without changing anything. {% stepper %} {% step %} ### Generate one event you can time by hand A sign-in is easiest. Note the wall-clock time to the minute. {% endstep %} {% step %} ### Open that event in the Webconsole and compare **Administration → Log Viewer** (`/webconsole/viewAuditLog`), open the event, and compare its rendered time with your wall clock. {% endstep %} {% step %} ### Find the same moment in a service log, and compare that A service log line is written and formatted in the service process's own zone, with no browser offset applied to it at all — which makes it the reading that has knob 3 taken out. Ask for the log covering that minute (see [Which log answers which question](/administration-guide/operations/which-log-to-read.md)) and find the sign-in. If the log and the screen disagree, the difference is knob 3: a browser offset being applied to the rendered value and not to the log. That is a rendering question, not a storage one. If they agree with each other and both disagree with your wall clock by a whole number of hours, the shift is below the UI, at knob 1 or knob 2. {% endstep %} {% step %} ### Confirm knob 3 by moving your own clock Change your workstation's timezone, sign in again, and re-read the same event on `/webconsole/viewAuditLog`. If the rendered time moves with your workstation, the viewer is applying your browser's offset and knob 3 is live. If it does not move, no offset is reaching the viewer and it is formatting in the UI service's own default zone — in which case only knobs 1 and 2 can explain the shift. {% endstep %} {% endstepper %} ## Verification You have a result when two readings of the same event disagree in a way that names one knob: screen and service log disagreeing is knob 3, screen and log agreeing but both out by a whole hour is knob 1 or knob 2. There is nothing to roll back — you changed nothing. ## The three knobs, and which one you are actually looking at | # | Knob | Whose layer it is | What it controls | | - | ------------------------------------------------------------------------------------ | ---------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ | | 1 | The session timezone on each database connection, which ships as UTC on all seven | Deployment — [Installation Guide](/installation/installation.md) | What the stored column value is, on write and on read | | 2 | The timezone the service processes run in | Deployment — [Installation Guide](/installation/installation.md) | The instant that gets stamped, how anything server-side is formatted, and the zone Quartz cron expressions on batch tasks are evaluated in | | 3 | The browser's timezone offset, sent by the login form and by audit search in minutes | Yours, per signed-in user | The zone the Webconsole renders each timestamp in | They act at different layers, in that order: knob 1 decides what is stored, knob 2 decides what was stamped and how anything server-side is formatted, knob 3 decides what one particular user sees. Change knob 1 and a user whose browser offset is being applied will see no difference at all. **Where the instant comes from.** An audit event takes its timestamp from the service that raises it, not from the database, and the same instant is copied onto the search document. So the moment recorded is decided by the service's own clock and zone (knob 2), the stored representation by the database connection's session zone (knob 1), and the two are independent of each other. **Where it is rendered.** The Webconsole audit viewer applies the *browser's* offset on top of whatever it read, and only when that offset is non-zero. When no offset arrives — which is the case for anything that is not a browser session — it falls back to formatting in the UI service's own default zone. That is why an integration reading the same events can report different times from the screen without either of them being wrong. ## Handing it to the deployment owner Knobs 1 and 2 are deployment-level: the database connections' session timezone and the timezone the service processes run in are both set where the deployment is defined, not in the Webconsole, and changing either requires the services to be restarted together. Hand that to whoever owns the deployment with the result of the comparison above, and see the [Installation Guide](/installation/installation.md). Two things are worth telling them: the setting is a parameter on each database connection rather than a standalone property, so adding a property will have no effect; and all seven connections have to move together, or two services will write the same instant in two different representations. {% hint style="warning" %} **Moving off UTC is usually not the answer.** Storing every row in UTC and converting at the edge is the safer design, and a uniform whole-hour shift is more often knob 2 or knob 3 than knob 1. Changing the stored zone fixes nothing a browser offset is causing. Nothing about the correct remedy for your deployment can be settled from configuration alone — do the comparison above on the running system first, and say which knob the evidence points at when you ask for a change. {% endhint %} The neighbouring knob has a consequence you own directly: Quartz cron expressions on batch tasks are evaluated in the batch-task-manager service's zone rather than the browser's, so `0 30 4 * * ?` is 04:30 in the *service's* zone. That is covered by [Create a batch task](/administration-guide/automation/batch-tasks.md). The certification service's own settings are quoted in full in [Operate certification services](/administration-guide/governance/certification/operate-certification-services.md). ## When it goes wrong | Symptom | Cause | Where to look / fix | | -------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------- | | Audit and log timestamps are exactly one hour earlier than wall-clock time | A whole-hour shift is timezone interpretation, never clock drift — one of three knobs | Start with the three-way comparison above | | Changed the database connections' timezone and the Webconsole still shows the old time | The audit viewer applies the browser's offset on top of the stored instant | Compare the screen against a service log line for the same moment | | An integration reports different times for the same events from the screen | No browser offset reaches it, so formatting falls back to the UI service's default zone | Expected, and neither reading is wrong. Making an integration render in a chosen zone is a **Developer Guide** matter | | A batch task fires at an unexpected hour | Quartz cron expressions are evaluated in the batch-task-manager service's zone, not the browser's | [Create a batch task](/administration-guide/automation/batch-tasks.md) | ## Related * [Find audit evidence](/administration-guide/operations/find-audit-evidence.md) — the audit search screen, its filters and what the trail can prove * [Diagnose a failed operation](/administration-guide/operations/diagnose-a-failed-operation.md) — the evidence layers, when the timestamps are right and the operation is not * [Create a batch task](/administration-guide/automation/batch-tasks.md) — the zone a cron expression is evaluated in * [Installation Guide](/installation/installation.md) — the database connections' session timezone and the zone the service processes run in *Applies to OpenIAM 2026.8.1. Last reviewed 7 August 2026.* --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.openiam.com/administration-guide/operations/timestamps-off-by-a-fixed-offset.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.