mindlesscloud opened a new pull request, #4932: URL: https://github.com/apache/incubator-devlake/pull/4932
### Summary ## Problem: A user reported a timezone-related issue with a Jira plugin: https://github.com/apache/incubator-devlake/issues/4902. The most important information is a log that the user provided, which includes a timestamp and some debug information. ```text time="2023-04-11 13:51:26" level=debug msg=" [pipeline service] [pipeline #2] [task #2] [collectIssues] fetchAsync >>> done for agile/1.0/board/1302/issue map[expand:[changelog] jql:[updated >= '2023/04/11 20:20' AND updated >= '2022/10/11 00:00' AND created is not null ORDER BY created ASC] maxResults:[100] startAt:[0]] <nil>" ``` ## Reason: There are two issues with the log: 1. the "updated" field appears twice in the JQL query 2. the log timestamp is earlier than the "updated" timestamp ```go if data.TimeAfter != nil { jql = fmt.Sprintf("updated >= '%v' AND %v", data.TimeAfter.Format("2006/01/02 15:04"), jql) } incremental := collectorWithState.IsIncremental() if incremental { jql = fmt.Sprintf("updated >= '%v' AND %v", collectorWithState.LatestState.LatestSuccessStart.Format("2006/01/02 15:04"), jql) } ``` Regarding the first issue, the root cause can be found in the code: the "updated" field is included twice because of some conditional logic that checks if a certain variable is not nil. The second issue is a bit more complex. The timestamp in the log comes from the variable "collectorWithState.LatestState.LatestSuccessStart", which is written to a database in UTC format by the GORM library. However, when this timestamp is read from the database and formatted into a string, the timezone information is lost. This can result in a timestamp that is different from the actual time, especially if the user is in a different timezone. ## Solution: For the first issue, the solution is to add a condition that checks which of the two "updated" fields is later and use that one. For the second issue, there are several possible solutions, but each has some drawbacks. One solution is to convert the timestamp to the user's local time before formatting it. However, this can lead to delays or data loss if the user's timezone is different from Jira's timezone. Another solution is to subtract a day from the timestamp before formatting it, but this can result in some data being collected twice. In this PR, we take the second one as our final solution. ### Does this close any open issues? Closes #4902 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
