Last login date is off

[ibuntumain]

whenever i see who logged in last itll say 5 hours ago everytime, i even set the timezone to mine and still says it, it also does it for last page edits too

[dfbustosus]

A constant offset on both login times and edit times — even for things that just happened — means the timestamps being compared are wrong by 5 hours somewhere. It's either storage-side or render-side, and you can tell them apart quickly:

1. Check what's actually stored. If you can reach the database:

SELECT email, last_login_at FROM users ORDER BY last_login_at DESC LIMIT 5;

Wiki.js stores these as UTC timestamps. Compare a fresh value against UTC now (date -u). If the stored value is ~5 hours in the past, the problem is at write time — go to step 2. If the stored value is correct, the problem is display-side — go to step 3.

2. Write-side: the server/container clock or TZ. Wiki.js (Node) derives times from the system clock; the admin-panel timezone setting does not shift stored timestamps. On Docker:

docker exec <wiki-container> date -u

If that's off, fix the host clock/daemon (and set TZ on the container to your zone for good measure: -e TZ=America/New_York, matching your offset). On bare metal, check timedatectl and that NTP is syncing. Note a constant 5 hours even across DST boundaries points at a fixed-offset misconfiguration rather than a wrong zone — e.g. the host believing it's UTC+5 or a VM snapshot restored with a stale clock.

3. Display-side: rule out browser/locale. Wiki.js renders relative times ("5 hours ago") client-side from ISO timestamps. Hard-refresh with cache bypass and check from a different browser/incognito — a stale cached bundle or a browser clock off by hours (common after sleep/resume on laptops) produces exactly this symptom on one machine while other viewers see correct times. If the times look wrong from every browser, it's storage-side (step 2).

Also worth knowing: default timezone for new users is a known, separately-tracked topic in Wiki.js (#2523, #2321) — but those affect at which wall-clock zone scheduled things and some displays happen, not whether a just-now login renders as "5 hours ago." Your symptom is a clock source problem, not a preference problem.

If you run step 1 and the stored last_login_at values are correct while every browser still shows +5h, that's a rendering bug worth reporting on the issue tracker with your Wiki.js version and locale — include what step 1 showed, since it pins which side is broken.

[ibuntumain]

ohhh ok that makes sense, thanks for the reply!

[NGPixel]

3.0.0-beta.711 now forces the timezone to UTC when connecting to the DB. It will only apply to stored dates going forward though. Your existing login timestamps will still be off.