diff --git a/docs/src/content/docs/en/spikes/tech-timezone-problem.mdx b/docs/src/content/docs/en/spikes/tech-timezone-problem.mdx
index e482d472b9..4bec16a17b 100644
--- a/docs/src/content/docs/en/spikes/tech-timezone-problem.mdx
+++ b/docs/src/content/docs/en/spikes/tech-timezone-problem.mdx
@@ -22,6 +22,8 @@ it is the method responsible for calculating failure rate.
 public ChangeFailureRate calculate(List<DeployTimes> deployTimesList)
 ```
 
+And when I use `San Francisco` timezone pick 9.20 - 9.21 in config page, the problem described by that card does not exist.
+
 This way can discovered that there is indeed some data on 9.19.Here's same case between 7.18-7.19.
  
 ### Trace
@@ -44,13 +46,48 @@ export const DateRangePicker = () => {
   ······
 }
 ```
+
+In heartbeat config, metrics, report pages, frontend transmits timestamp or special timezone time to the backend.
+This is what the browser gets based on the time zone after the user selects the time in the date picker,
+such as:
+```json
+{
+  "startTime": 1689609600000,
+  "endTime": 1689811199999
+}
+```
+or
+```json
+{
+  "startTime": "2023-07-18T00:00:00.000+08:00",
+  "endTime": "2023-07-19T23:59:59.999+00:00"
+}
+```
+ 
+So we can get the date handler logic:
+
+```plantuml
+@startuml
+skin rose
+start
+
+:user configs date picker in customer's browser;
+:transmits the local time of its location to the frontend;
+:frontend converts it timestamp or a specific timezone time for the backend;
+:backend transmits it for third-party remote api;
+stop
+
+@enduml
+```
  
 ### Result
 According to the analysis of the code, the logic of the system is that,
 the time selected by the date picker is passed to the backend according to the user's time zone,
-and the backend converts it to the standard UTC time and then passes it to the third feign api.
+then the backend passes it to the third-party api.
 
-When I use `San Francisco` timezone pick 9.20 - 9.21 in config page, the problem described by that card does not exist.
+The logic of our system is that the time selected by the user through the date picker can cover the Jira, Buildkite,
+and GitHub data corresponding to the local time of the region.
 
-Through the above analysis, the problem described in that card is distorted.
-The system has normal and correct logic, and the user's needs can also be met.We don't need to make code changes.
+There is a situation, when a user wants to get report about a time zone different from own browser,
+there will be a certain gap. For example, if a user in China wants to get the report from 9.20 to 9.21 in Australia,
+the data selected through the date picker will be biased.