Dashboard time displays in UTC

[Erasure5959]

Hello,

The time on the dashboard displays in UTC for me, as shown below:

My current offset is +2; the log timestamps are correct but the dashboard is two hours behind which can make correlation a little bit tricky.

I couldn't find anything in the documentation regarding setting the timezone for the dashboard, only the logs. I attempted to mount the below into the frontend container:

    volumes:
      - /etc/localtime:/etc/localtime:ro
      - /etc/timezone:/etc/timezone:ro

This has not made any difference though. From inside the container:

/app/packages/frontend # date
Tue Jul  7 15:52:45 UTC 2026

I see the localtime file appears to be garbled inside the container, perhaps some kind of parsing issue?

I can also see my timezone as an environment variable inside the container; I set this in the .env file in the hopes it would help.

Likely I have misconfigured something here, any ideas where I might have gone wrong?

[Polliog]

Thanks for the detailed report. We've confirmed the dashboard renders times in the browser's timezone and there's currently no display-timezone setting (mounting /etc/localtime into the frontend container has no effect since rendering is client-side). We're still investigating and deciding which way to go here, so any feedback is very welcome.

[Erasure5959]

Hmmm thanks, that makes sense but then perhaps something else is up. My browser reports the correct timezone (Microsoft Edge v150):

Intl.DateTimeFormat().resolvedOptions().timeZone
'Africa/Johannesburg'

Will do some further digging with other browsers and experiment with settings and extensions, maybe some read functionality is being blocked somewhere.

[Polliog]

Thanks, that rules out the browser timezone. We reproduced the chart pipeline and it renders in the browser's local zone, so we're missing something specific to your instance. Two things would pin it down: (1) which LogTide version you're running, and (2) the raw values the chart receives - open DevTools > Network, reload the project overview, click the activity-overview request, and paste a couple of the series[].time values from the Response tab. That tells us instantly whether the offset is in the data or the rendering.

[Erasure5959]

Not sure if I am being stupid, but I am not seeing the activity-overview request. I am running 1.0.3. I'll dig a bit more tomorrow from another machine, I saw the same behaviour from my phone. Entirely possible I have made a mistake somewhere in the setup.

[Polliog]

We think we've found it, and it may not be a timezone issue at all. The Activity Overview chart reads from a rolling hourly rollup that lags real time by 1-2 hours, while the logs view reads live data - so the chart's recent edge can look "behind" even when the axis is correct. Could you confirm one thing: on the chart, does the logs line drop to zero roughly 1-2 hours before the current time, even though logs for that window do appear in the logs view? If yes, that's the rollup lag and we'll fix the panel to backfill the recent tail from live data.

[Erasure5959]

Yes, I think that might be it. Graph lines up with what you describe:

Current time is 22:33, you can see it drops to 0 around 1.5 hours behind current time. Does that help?

EDIT: just to confirm, yes I am still receiving logs:

[Polliog]

Perfect, that confirms it - thanks for checking. It's not a timezone issue: the Activity Overview chart is fed by an hourly rollup that intentionally lags live data by 1-2 hours, while your logs view reads live data, so the chart's recent tail shows empty. We'll fix the panel to backfill that recent window from live data. Tracking it here; the fix will land on the develop branch.