Is there an existing issue for this?
Current behavior
Setting a timezone in workspace settings (e.g. Asia/Hong_Kong) has no effect on any time display in the app. workspaces.timezone is only used on the settings page itself and never participates in rendering logic.
On the home page, the greeting header shows a time that does not match either the workspace timezone or the browser timezone. Example: workspace timezone set to Asia/Hong_Kong, browser in GMT+8, wall-clock time 12:33 — the header renders Good afternoon (correct, from browser time) together with 04:33 (UTC, wrong).
The same row mixes two different timezones:
hour / date / weekDay are formatted without a timeZone option → browser local timezonetimeString is formatted with timeZone: user.user_timezone → the user's profile timezone, which defaults to UTC in the database for anyone who never picked one
So the greeting word ("morning/afternoon/evening") and the displayed clock time can belong to different timezones, and neither respects the workspace timezone. The profile sidebar time (ProfileSidebarTime) has the same single-source problem: it only uses user_timezone.
Steps to reproduce
- Set a non-UTC timezone in workspace settings (Settings → Workspace → Timezone, e.g.
Asia/Hong_Kong).
- Leave the personal profile timezone untouched (it stays at the DB default
UTC).
- Open the workspace home page.
- Observe: the greeting uses the browser timezone (e.g. "Good afternoon") while the displayed time is in UTC (e.g.
04:33 instead of 12:33), and the workspace timezone is ignored entirely.
Expected behavior
Time displays resolve the timezone in a sensible priority order: the user's explicitly chosen profile timezone → the workspace timezone → the browser's local timezone. All fields on the greeting row (greeting word, weekday, date, time) should use the same timezone.
Root cause analysis
apps/web/core/components/home/user-greetings.tsx and apps/web/core/components/user/user-greetings.tsx: timeString passes timeZone: user?.user_timezone while hour/date/weekDay pass no timeZone at all — two timezones on one row, and no reference to the workspace timezone.apps/web/core/components/profile/time.tsx (ProfileSidebarTime): formats solely with the profile user_timezone.workspaces.timezone appears only in the workspace settings UI and is never read for display purposes.
A note on the fallback semantics: UTC is the database default for user_timezone, so a user who never set a preference is indistinguishable from one who deliberately picked UTC. Treating UTC as "unset" and falling back to the organization-declared workspace timezone produces the expected result for the far more common case.
I have a fix ready and will open a PR referencing this issue.
Environment
Production / self-hosted and local dev
Browser
Google Chrome
Version
v1.4.2 / master
Is there an existing issue for this?
Current behavior
Setting a timezone in workspace settings (e.g.
Asia/Hong_Kong) has no effect on any time display in the app.workspaces.timezoneis only used on the settings page itself and never participates in rendering logic.On the home page, the greeting header shows a time that does not match either the workspace timezone or the browser timezone. Example: workspace timezone set to
Asia/Hong_Kong, browser in GMT+8, wall-clock time 12:33 — the header rendersGood afternoon(correct, from browser time) together with04:33(UTC, wrong).The same row mixes two different timezones:
hour/date/weekDayare formatted without atimeZoneoption → browser local timezonetimeStringis formatted withtimeZone: user.user_timezone→ the user's profile timezone, which defaults toUTCin the database for anyone who never picked oneSo the greeting word ("morning/afternoon/evening") and the displayed clock time can belong to different timezones, and neither respects the workspace timezone. The profile sidebar time (
ProfileSidebarTime) has the same single-source problem: it only usesuser_timezone.Steps to reproduce
Asia/Hong_Kong).UTC).04:33instead of12:33), and the workspace timezone is ignored entirely.Expected behavior
Time displays resolve the timezone in a sensible priority order: the user's explicitly chosen profile timezone → the workspace timezone → the browser's local timezone. All fields on the greeting row (greeting word, weekday, date, time) should use the same timezone.
Root cause analysis
apps/web/core/components/home/user-greetings.tsxandapps/web/core/components/user/user-greetings.tsx:timeStringpassestimeZone: user?.user_timezonewhilehour/date/weekDaypass notimeZoneat all — two timezones on one row, and no reference to the workspace timezone.apps/web/core/components/profile/time.tsx(ProfileSidebarTime): formats solely with the profileuser_timezone.workspaces.timezoneappears only in the workspace settings UI and is never read for display purposes.A note on the fallback semantics:
UTCis the database default foruser_timezone, so a user who never set a preference is indistinguishable from one who deliberately picked UTC. TreatingUTCas "unset" and falling back to the organization-declared workspace timezone produces the expected result for the far more common case.I have a fix ready and will open a PR referencing this issue.
Environment
Production / self-hosted and local dev
Browser
Google Chrome
Version
v1.4.2 / master