Question
Inconsistent Last Modified timestamps in ProcessWire admin interface
Dev Indigo
0 reputation · 06 Dec 2020, 21:29 UTC
94.7K views1
Loading…
0 reputation · 06 Dec 2020, 21:29 UTC
ProcessWire stores page dates as Unix timestamps in the database, which provides a timezone-agnostic baseline. While the $page->date() method allows for regional formatting via PHP's date syntax, the administrative interface relies on server-level PHP configurations (date.timezone) to render modification times.
A discrepancy occurs when the server's system time differs from the administrator's local regional time zone. Because ProcessWire does not currently implement a per-user timezone mapping for the backend, the 'Last Modified' metadata may reflect the server's offset rather than the user's actual local time.
php.ini settings for global time resolution.Does ProcessWire provide a mechanism to override the server timezone for specific administrative users? How can the admin interface be configured to display timestamps relative to the user's local browser time instead of the server's PHP configuration?
ProcessWire does not provide a built-in per-user timezone override for the admin interface. The admin renders all 'Last Modified' timestamps using the server's PHP timezone (php.ini date.timezone or $config->timezone in site/config.php). This means every admin user sees the same offset, regardless of their local browser timezone.
processwiredate() function, which uses a single global timezone.$page->modified returns a Unix timestamp; formatting uses ->modified('Y-m-d H:i:s T', $config->timezone).$config->timezone in site/config.php applies site-wide and affects front-end $page->date() as well.UserTimezone or AdminTimezone add per-user fields but require template overrides or JavaScript injection to rewrite admin list views.date('Y-m-d H:i:s T', $page->modified) or check wire('config')->timezone.$config->timezone = 'America/New_York'; in site/config.php.Intl.DateTimeFormat().resolvedOptions().timeZone in the browser and converts the Unix timestamp client-side.Could you confirm whether the requirement is a site-wide timezone offset or per-user browser-local display? This detail determines whether a simple config.php change or a custom JavaScript solution is the appropriate next step.
Use comments to ask for clarification. Post a solution as an answer.
34,775 reputation · 07 Dec 2020, 02:30 UTC
One detail worth adding to the steps above: avoid hard-coding a fixed offset like UTC-5 anywhere in this chain. Both $config->timezone and any JavaScript conversion should use an IANA zone name (America/New_York), because fixed offsets silently drift by an hour when daylight saving rules change, which is a common cause of "the timestamp was right last month" reports.
Also, a lighter hybrid than a full custom module: ProcessWire admin markup generally includes the raw Unix timestamp in the rendered HTML (check the element's title attribute or a data-* attribute on the modified column in your version — verify in DevTools, as this varies by admin theme). If present, a small JS snippet loaded via $config->adminJS or an admin theme override can rewrite those nodes in place with new Date(ts * 1000).toLocaleString(), leaving the server-rendered value as the fallback for non-JS contexts.