langgenius/dify
1
0
Fork 0
mirror of https://github.com/langgenius/dify.git synced 2026-07-20 19:50:06 -04:00
Code Issues 775 Packages Projects Releases 10 Wiki Activity

[PR #32119] fix(web): use user profile timezone for date range filtering #33559

New Issue
Open
opened 2026-02-21 20:53:30 -05:00 by yindo · 0 comments
yindo commented 2026-02-21 20:53:30 -05:00
Owner
Copy Link
Copy Source

Original Pull Request: https://github.com/langgenius/dify/pull/32119

State: open
Merged: No

close https://github.com/langgenius/dify/issues/32121

1. What was the problem?

When running Dify in a local development environment (e.g., Docker), the host machine's time might differ from the database's UTC time due to time drift or timezone misconfiguration.
For example, the host machine might think it's February 8th , while the data in the database is timestamped February 9th (UTC).

Previously, when a user clicked the "Today" filter button, the frontend code naively relied on the browser/system local time ( dayjs() ) to calculate the start and end query parameters.

  • Scenario: The user clicks "Today".
  • Old Behavior: The browser (host) says "It's Feb 8th", so the query requests data for Feb 8th.
  • Result: The query returns empty results because the relevant data in the database is actually on Feb 9th.

2. What did I fix?

I modified the date calculation logic in the frontend to enforce the use of the User Profile Timezone instead of the local system time.

  • The code now uses dayjs().tz(userProfile.timezone) to determine the current date relative to the user's configured settings.
  • New Behavior: Even if the host computer says "Feb 8th", if the user's profile is set to a timezone where it is already "Feb 9th" (or aligns with the server data), the query will correctly request data for Feb 9th .
  • This ensures that date range filters (Today, Last 7 days, etc.) work universally, regardless of the local machine's clock drift or timezone differences.

Modified Components:

  1. Log List ( app/components/app/log/index.tsx ) : Updated start and end param generation.

  2. Chart View ( overview/chart-view.tsx ) : Updated chart data initialization logic.

  3. Time Range Pickers :

    • overview/long-time-range-picker.tsx
    • overview/time-range-picker/index.tsx
    • overview/time-range-picker/range-selector.tsx [!IMPORTANT]

  4. Make sure you have read our https://github.com/langgenius/dify/blob/main/CONTRIBUTING.md

  5. Ensure there is an associated issue and you have been assigned to it

  6. Use the correct syntax to link this PR: Fixes # .

Summary

This PR fixes a bug where date range filters returned empty results in environments with time drift or timezone mismatches (e.g., local Docker vs. host). It forces the frontend to calculate date ranges based on the user's configured profile timezone, ensuring queries align with the stored data.

Screenshots

Before
de045d0f649ae4be9df11d078eeb5b5e
2eb66b05e0bd0051ea67c585e3fa6d6e

After
image

Checklist

  • This change requires a documentation update, included: https://github.com/langgenius/dify-docs (Not strictly required as this is a bug fix, but good to note timezone behavior)
  • I understand that this PR may be closed in case there was no previous discussion or issues.
  • I've added a test for each change that was introduced, and I tried as much as possible to make a single atomic change.
  • I've updated the documentation accordingly.
  • I ran make lint and make type-check (backend) and cd web && npx lint-staged (frontend) to appease the lint gods.
**Original Pull Request:** https://github.com/langgenius/dify/pull/32119 **State:** open **Merged:** No --- close https://github.com/langgenius/dify/issues/32121 ### 1. What was the problem? When running Dify in a local development environment (e.g., Docker), the host machine's time might differ from the database's UTC time due to time drift or timezone misconfiguration. For example, the host machine might think it's February 8th , while the data in the database is timestamped February 9th (UTC). Previously, when a user clicked the "Today" filter button, the frontend code naively relied on the browser/system local time ( dayjs() ) to calculate the start and end query parameters. - Scenario: The user clicks "Today". - Old Behavior: The browser (host) says "It's Feb 8th", so the query requests data for Feb 8th. - Result: The query returns empty results because the relevant data in the database is actually on Feb 9th. ### 2. What did I fix? I modified the date calculation logic in the frontend to enforce the use of the User Profile Timezone instead of the local system time. - The code now uses dayjs().tz(userProfile.timezone) to determine the current date relative to the user's configured settings. - New Behavior: Even if the host computer says "Feb 8th", if the user's profile is set to a timezone where it is already "Feb 9th" (or aligns with the server data), the query will correctly request data for Feb 9th . - This ensures that date range filters (Today, Last 7 days, etc.) work universally, regardless of the local machine's clock drift or timezone differences. ### Modified Components: 1. Log List ( app/components/app/log/index.tsx ) : Updated start and end param generation. 2. Chart View ( overview/chart-view.tsx ) : Updated chart data initialization logic. 3. Time Range Pickers : - overview/long-time-range-picker.tsx - overview/time-range-picker/index.tsx - overview/time-range-picker/range-selector.tsx [!IMPORTANT] 1. Make sure you have read our https://github.com/langgenius/dify/blob/main/CONTRIBUTING.md 2. Ensure there is an associated issue and you have been assigned to it 3. Use the correct syntax to link this PR: Fixes #<issue number> . ## Summary This PR fixes a bug where date range filters returned empty results in environments with time drift or timezone mismatches (e.g., local Docker vs. host). It forces the frontend to calculate date ranges based on the user's configured profile timezone, ensuring queries align with the stored data. ## Screenshots Before <img width="2553" height="915" alt="de045d0f649ae4be9df11d078eeb5b5e" src="https://github.com/user-attachments/assets/f088319a-8feb-4b56-8149-8897bd0f8a06"/> <img width="2556" height="714" alt="2eb66b05e0bd0051ea67c585e3fa6d6e" src="https://github.com/user-attachments/assets/08bcd117-bfa4-421e-9da1-54ca347fd2de"/> After <img width="2553" height="840" alt="image" src="https://github.com/user-attachments/assets/31086dbc-4f5c-4f54-a909-e201efe5d744" /> ## Checklist - This change requires a documentation update, included: https://github.com/langgenius/dify-docs (Not strictly required as this is a bug fix, but good to note timezone behavior) - I understand that this PR may be closed in case there was no previous discussion or issues. - I've added a test for each change that was introduced, and I tried as much as possible to make a single atomic change. - I've updated the documentation accordingly. - I ran make lint and make type-check (backend) and cd web && npx lint-staged (frontend) to appease the lint gods.
yindo added the pull-request label 2026-02-21 20:53:30 -05:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Knowledge Pipeline
Proposal
WIP
cloud
dependencies
feat:webapp
good first issue
outdated
performance
pull-request
Mirrored from GitHub Pull Request
 python:uv
refactor
size:L
stale
status: accepting prs
status: blocked
status: in discussion
stt & tts
vulnerablity
web
wont-fix
🌊 feat:workflow
🌚 invalid
🐞 bug
👻 feat:rag
💪 enhancement
📚 documentation
🔨 feat:tools
🙋‍♂️ question
🙏 help wanted
🤔 cant-reproduce
🤖 feat:agent
No Label pull-request
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: langgenius/dify#33559
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?