fix(web): use user profile timezone for date range filtering#32119
fix(web): use user profile timezone for date range filtering#32119Theysua wants to merge 0 commit into
Conversation
dosubot
Bot
added
the
size:M
Summary of ChangesHello @Theysua, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request addresses a critical bug where date range filters in the application would return empty results due to mismatches between the local system's time and the database's UTC timestamps, particularly in development environments like Docker. By enforcing the use of the user's configured profile timezone for all date calculations, the changes ensure that frontend queries accurately reflect the intended time periods, leading to consistent and correct data retrieval regardless of environmental time differences. Highlights
🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console. Changelog
Activity
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request aims to fix a bug where date range filters were using the local system time instead of the user's configured timezone, leading to incorrect data being displayed. The approach of using dayjs().tz(userProfile.timezone) is correct. However, I've found a couple of instances where the implementation doesn't fully resolve the issue due to how React's useState hook initializes state from props/context that might not be available on the initial render. My review includes suggestions to address this by using the useEffect hook for state initialization. I've also included a minor suggestion to improve code readability.
| const [period, setPeriod] = useState<PeriodParams>(IS_CLOUD_EDITION | ||
| ? { name: t('filter.period.today', { ns: 'appLog' }), query: { start: today.startOf('day').format(queryDateFormat), end: today.endOf('day').format(queryDateFormat) } } | ||
| : { name: t('filter.period.last7days', { ns: 'appLog' }), query: { start: today.subtract(7, 'day').startOf('day').format(queryDateFormat), end: today.endOf('day').format(queryDateFormat) } }, | ||
| ? { name: t('filter.period.today', { ns: 'appLog' }), query: { start: dayjs().tz(userProfile?.timezone).startOf('day').format(queryDateFormat), end: dayjs().tz(userProfile?.timezone).endOf('day').format(queryDateFormat) } } | ||
| : { name: t('filter.period.last7days', { ns: 'appLog' }), query: { start: dayjs().tz(userProfile?.timezone).subtract(7, 'day').startOf('day').format(queryDateFormat), end: dayjs().tz(userProfile?.timezone).endOf('day').format(queryDateFormat) } }, | ||
| ) |
There was a problem hiding this comment.
There's a potential issue here with the initialization of the period state. The useState initializer is executed only on the first render. At that point, userProfile might not be fully loaded, and userProfile?.timezone could be undefined. This would cause dayjs().tz() to fall back to the local system's timezone, which is the exact bug this PR aims to fix. When userProfile eventually loads, this state won't be re-initialized.
To fix this, you could consider initializing the state with null and then setting it inside a useEffect hook that depends on userProfile?.timezone. This ensures the initial period is always calculated with the correct timezone. You would then need to handle the null state, for example by showing a loading indicator until the state is set.
Additionally, dayjs().tz(userProfile?.timezone) is called multiple times. Defining a today variable within the effect would make the code cleaner.
| start: dayjs().tz(userProfile?.timezone).subtract(TIME_PERIOD_MAPPING[debouncedQueryParams.period].value, 'day').startOf('day').format('YYYY-MM-DD HH:mm'), | ||
| end: dayjs().tz(userProfile?.timezone).endOf('day').format('YYYY-MM-DD HH:mm'), |
There was a problem hiding this comment.
For better readability and to avoid redundant calls, you could extract dayjs().tz(userProfile?.timezone) into a today variable before constructing the query object and use it in both start and end date calculations.
1 participant
close #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.
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.
Modified Components:
Log List ( app/components/app/log/index.tsx ) : Updated start and end param generation.
Chart View ( overview/chart-view.tsx ) : Updated chart data initialization logic.
Time Range Pickers :
Make sure you have read our https://github.com/langgenius/dify/blob/main/CONTRIBUTING.md
Ensure there is an associated issue and you have been assigned to it
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
After
Checklist