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

Logs&Anns page “created_at” field is not displayed correctly by timezone #5370

New Issue
Closed
opened 2026-02-21 18:10:38 -05:00 by yindo · 7 comments
yindo commented 2026-02-21 18:10:38 -05:00
Owner
Copy Link
Copy Source

Originally created by @cesar-blog on GitHub (Sep 3, 2024).

Self Checks

  • This is only for bug report, if you would like to ask a question, please head to Discussions.
  • I have searched for existing issues search for existing issues, including closed ones.
  • I confirm that I am using English to submit this report (我已阅读并同意 Language Policy).
  • [FOR CHINESE USERS] 请务必使用英文提交 Issue，否则会被关闭。谢谢！:）
  • Please do not modify this template :) and fill in all the required fields.

Dify version

0.7.3

Cloud or Self Hosted

Self Hosted (Docker)

Steps to reproduce

  1. setting->language-> display language set 简体中文 ; timezone set +8 shanghai/beijing
  2. start a chat session
  3. go to Logs&Anns page to view records
  4. created_at field is not displayed correctly by timezone

✔️ Expected Behavior

created_at & updated_at field can be correctly displayed by timezone

The local environment is displayed correctly but the production environment is not

SETTING
image

The local environment：
DB
image

SYSTEM
image

The production environment：
DB
image

SYSTEM
image

❌ Actual Behavior

The production environment：

image
Originally created by @cesar-blog on GitHub (Sep 3, 2024). ### Self Checks - [X] This is only for bug report, if you would like to ask a question, please head to [Discussions](https://github.com/langgenius/dify/discussions/categories/general). - [X] I have searched for existing issues [search for existing issues](https://github.com/langgenius/dify/issues), including closed ones. - [X] I confirm that I am using English to submit this report (我已阅读并同意 [Language Policy](https://github.com/langgenius/dify/issues/1542)). - [X] [FOR CHINESE USERS] 请务必使用英文提交 Issue，否则会被关闭。谢谢！:） - [X] Please do not modify this template :) and fill in all the required fields. ### Dify version 0.7.3 ### Cloud or Self Hosted Self Hosted (Docker) ### Steps to reproduce 1. setting->language-> display language set 简体中文 ; timezone set +8 shanghai/beijing 2. start a chat session 3. go to Logs&Anns page to view records 4. created_at field is not displayed correctly by timezone ### ✔️ Expected Behavior created_at & updated_at field can be correctly displayed by timezone **The local environment is displayed correctly but the production environment is not** SETTING <img width="810" alt="image" src="https://github.com/user-attachments/assets/6de84b17-9d86-4875-861a-cc939abb8340"> **The local environment：** DB <img width="529" alt="image" src="https://github.com/user-attachments/assets/a8a6cc47-dc5f-4497-a539-1243e1824edd"> SYSTEM <img width="915" alt="image" src="https://github.com/user-attachments/assets/3cfbb905-226e-4875-8875-7da275f799fa"> **The production environment：** DB <img width="353" alt="image" src="https://github.com/user-attachments/assets/a9b5c7aa-f18f-46fe-b335-82f056010534"> SYSTEM <img width="505" alt="image" src="https://github.com/user-attachments/assets/8962fc7b-3e03-43cd-82ac-6e48ee48c962"> ### ❌ Actual Behavior **The production environment：** <img width="818" alt="image" src="https://github.com/user-attachments/assets/70836a55-3a54-42f1-9ada-fd661a528029">
yindo added the 🐞 bug label 2026-02-21 18:10:38 -05:00
yindo closed this issue 2026-02-21 18:10:38 -05:00
yindo commented 2026-02-21 18:10:38 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (Sep 3, 2024):

@cesar-blog Hello there! I'm here to assist you with any bugs, questions, or contributions you have regarding the repository. Let's work together to resolve this issue.

The issue with the "created_at" field not displaying correctly by timezone in the production environment is likely due to the timezone extension not being applied correctly when formatting the time.

In the DetailPanel component, the fetchData function formats the chat list with the timezone:

const newItems = [...getFormattedChatList(messageRes.data, detail.id, timezone!, t('appLog.dateTimeFormat') as string), ...items]

However, there is no evidence in the provided code that the timezone extension is being used when formatting the created_at field. Ensure that the dayjs library is correctly configured to use the timezone extension when formatting dates.

Here is an example of how you can ensure the created_at field is formatted with the correct timezone:

import dayjs from 'dayjs'
import utc from 'dayjs/plugin/utc'
import timezone from 'dayjs/plugin/timezone'

dayjs.extend(utc)
dayjs.extend(timezone)

// Example of formatting the created_at field with timezone
const formattedCreatedAt = dayjs(item.annotation_hit_history.created_at).tz(timezone).format('YYYY-MM-DD HH:mm:ss')

Make sure that the timezone is correctly passed and used in the formatting function. This should resolve the discrepancy between the local and production environments [1].

To continue talking to Dosu, mention @dosu.

@dosubot[bot] commented on GitHub (Sep 3, 2024): <!-- Greeting --> @cesar-blog Hello there! I'm here to assist you with any bugs, questions, or contributions you have regarding the repository. Let's work together to resolve this issue. <!-- Answer --> The issue with the "created_at" field not displaying correctly by timezone in the production environment is likely due to the timezone extension not being applied correctly when formatting the time. In the `DetailPanel` component, the `fetchData` function formats the chat list with the timezone: ```tsx const newItems = [...getFormattedChatList(messageRes.data, detail.id, timezone!, t('appLog.dateTimeFormat') as string), ...items] ``` However, there is no evidence in the provided code that the `timezone` extension is being used when formatting the `created_at` field. Ensure that the `dayjs` library is correctly configured to use the timezone extension when formatting dates. Here is an example of how you can ensure the `created_at` field is formatted with the correct timezone: ```tsx import dayjs from 'dayjs' import utc from 'dayjs/plugin/utc' import timezone from 'dayjs/plugin/timezone' dayjs.extend(utc) dayjs.extend(timezone) // Example of formatting the created_at field with timezone const formattedCreatedAt = dayjs(item.annotation_hit_history.created_at).tz(timezone).format('YYYY-MM-DD HH:mm:ss') ``` Make sure that the `timezone` is correctly passed and used in the formatting function. This should resolve the discrepancy between the local and production environments <sup>[[1]](https://github.com/langgenius/dify/blob/main/web/app/components/app/log/list.tsx)</sup>. <!-- Dosu Comment Footer --> *To continue talking to [Dosu](https://dosu.dev), mention @dosu.*
yindo commented 2026-02-21 18:10:38 -05:00
Author
Owner
Copy Link
Copy Source

@cesar-blog commented on GitHub (Sep 3, 2024):

The local environment interface has returned +8 hours

image image
@cesar-blog commented on GitHub (Sep 3, 2024): The local environment interface has returned +8 hours <img width="801" alt="image" src="https://github.com/user-attachments/assets/3ff8f5c4-2fb3-44b0-9fdd-7bd01b3c0ef0"> <img width="924" alt="image" src="https://github.com/user-attachments/assets/df569535-a310-47ab-85ba-238896195a86">
yindo commented 2026-02-21 18:10:38 -05:00
Author
Owner
Copy Link
Copy Source

@cesar-blog commented on GitHub (Sep 3, 2024):

@dosu.

@cesar-blog commented on GitHub (Sep 3, 2024): @dosu.
yindo commented 2026-02-21 18:10:38 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (Sep 3, 2024):

The issue with the created_at field not displaying correctly by timezone in the production environment might be due to how the timestamps are being processed and displayed.

In the Dify codebase, the dayjs library is used with the utc and timezone plugins to handle timezone conversions. Ensure that the dayjs library is correctly configured and used in your production environment to format timestamps according to the user's timezone.

Here is an example of how dayjs is configured and used:

import dayjs from 'dayjs'
import utc from 'dayjs/plugin/utc'
import timezone from 'dayjs/plugin/timezone'

dayjs.extend(utc)
dayjs.extend(timezone)

const useTimestamp = () => {
  const { userProfile: { timezone } } = useAppContext()

  const formatTime = useCallback((value: number, format: string) => {
    return dayjs.unix(value).tz(timezone).format(format)
  }, [timezone])

  return { formatTime }
}

Make sure that the timezone is correctly passed and used in the formatting function. This should resolve the discrepancy between the local and production environments [1].

Additionally, verify that the backend services are correctly converting timestamps to UTC and then adjusting them to the user's timezone before sending them to the frontend. This is crucial for consistent timestamp handling across different environments [2][3][4].

To continue talking to Dosu, mention @dosu.

@dosubot[bot] commented on GitHub (Sep 3, 2024): <!-- Answer --> The issue with the `created_at` field not displaying correctly by timezone in the production environment might be due to how the timestamps are being processed and displayed. In the Dify codebase, the `dayjs` library is used with the `utc` and `timezone` plugins to handle timezone conversions. Ensure that the `dayjs` library is correctly configured and used in your production environment to format timestamps according to the user's timezone. Here is an example of how `dayjs` is configured and used: ```ts import dayjs from 'dayjs' import utc from 'dayjs/plugin/utc' import timezone from 'dayjs/plugin/timezone' dayjs.extend(utc) dayjs.extend(timezone) const useTimestamp = () => { const { userProfile: { timezone } } = useAppContext() const formatTime = useCallback((value: number, format: string) => { return dayjs.unix(value).tz(timezone).format(format) }, [timezone]) return { formatTime } } ``` Make sure that the `timezone` is correctly passed and used in the formatting function. This should resolve the discrepancy between the local and production environments <sup>[[1]](https://github.com/langgenius/dify/blob/main/web/hooks/use-timestamp.ts)</sup>. Additionally, verify that the backend services are correctly converting timestamps to UTC and then adjusting them to the user's timezone before sending them to the frontend. This is crucial for consistent timestamp handling across different environments <sup>[[2]](https://github.com/langgenius/dify/blob/main/api/controllers/console/app/statistic.py)</sup><sup>[[3]](https://github.com/langgenius/dify/blob/main/api/controllers/console/app/conversation.py)</sup><sup>[[4]](https://github.com/langgenius/dify/blob/main/api/controllers/console/app/workflow_statistic.py)</sup>. <!-- Dosu Comment Footer --> *To continue talking to [Dosu](https://dosu.dev), mention @dosu.*
yindo commented 2026-02-21 18:10:39 -05:00
Author
Owner
Copy Link
Copy Source

@crazywoola commented on GitHub (Sep 3, 2024):

https://github.com/langgenius/dify/blob/d7aa4076c9972b8e881c311dfdc4f2aa17277a3f/web/app/components/app/log/list.tsx#L717-L718

I took a look at this code, it seems to use the right function to format time already.

@crazywoola commented on GitHub (Sep 3, 2024): https://github.com/langgenius/dify/blob/d7aa4076c9972b8e881c311dfdc4f2aa17277a3f/web/app/components/app/log/list.tsx#L717-L718 I took a look at this code, it seems to use the right function to format time already.
yindo commented 2026-02-21 18:10:39 -05:00
Author
Owner
Copy Link
Copy Source

@cesar-blog commented on GitHub (Sep 3, 2024):

https://github.com/langgenius/dify/blob/d7aa4076c9972b8e881c311dfdc4f2aa17277a3f/web/app/components/app/log/list.tsx#L717-L718

I took a look at this code, it seems to use the right function to format time already.

It shouldn't be the front end. Look at the interface return.

The local environment interface has returned +8 hours but the production environment is not

@cesar-blog commented on GitHub (Sep 3, 2024): > https://github.com/langgenius/dify/blob/d7aa4076c9972b8e881c311dfdc4f2aa17277a3f/web/app/components/app/log/list.tsx#L717-L718 > > I took a look at this code, it seems to use the right function to format time already. It shouldn't be the front end. Look at the interface return. **The local environment interface has returned +8 hours but the production environment is not**
yindo commented 2026-02-21 18:10:39 -05:00
Author
Owner
Copy Link
Copy Source

@cesar-blog commented on GitHub (Sep 3, 2024):

Changing the timezone(UTC) of the container where the api resides solves the problem

image
@cesar-blog commented on GitHub (Sep 3, 2024): Changing the timezone(UTC) of the container where the api resides solves the problem <img width="353" alt="image" src="https://github.com/user-attachments/assets/d119ffaf-ac7d-4df4-9eb0-96ee5d05b019">
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 🐞 bug
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#5370
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?