[bug]: Workspace timezone setting is ignored — home greeting and profile times mix two timezones
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 59.6k
- Forks
- 5.8k
- Avg merge
- 1d 22h
- Merged PRs (30d)
- 49
Description
Is there an existing issue for this?
- I have searched the existing issues
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/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 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: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: 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
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with apps/web/core/components/home/user-greetings.tsx, apps/web/core/components/user/user-greetings.tsx, and apps/web/core/components/profile/time.tsx, then trace how workspace and profile timezones are provided. Reproduce the issue with a UTC profile default and a non-UTC workspace timezone. Done means the greeting fields and profile sidebar consistently resolve and display the intended timezone, with browser time as the final fallback.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- react, typescript
- Domain
- frontend
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Active
- Clarity
- Clearly specified
- Newbie friendliness
- 35/100