makeplane / makeplane/plane

[bug]: Workspace timezone setting is ignored — home greeting and profile times mix two timezones

Open
#9,795 0 comments 0 reactions 0 assignees View on GitHub

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 / weekDay are formatted without a timeZone option → browser local timezone
  • timeString 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
  1. Set a non-UTC timezone in workspace settings (Settings → Workspace → Timezone, e.g. Asia/Hong_Kong).
  2. Leave the personal profile timezone untouched (it stays at the DB default UTC).
  3. Open the workspace home page.
  4. 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

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.