TJX2014 edited a comment on pull request #28918: URL: https://github.com/apache/spark/pull/28918#issuecomment-649602460
> @TJX2014 thanks for providing a patch, in general it would be great if you can provide more detailed description of the problem as well as the fix to help the reviewers easily understand what is going on. You spent time debugging so just sharing your analysis is great. > In this case it would be nice to point to exactly where in 2.4 it was using string and then in 3.0 where it was changed and perhaps an example of the format change. It also is useful to say how/why your change fixes this issue. In this case it seems like its formatting it differently. For instance it doesn't looks like the launchTime in the TaskData structure changed at all, it is a Date in both 2.4 and 3.0. > > 2.4 calls UIUtils.formatDate which returns a string: https://github.com/apache/spark/blob/branch-2.4/core/src/main/scala/org/apache/spark/ui/jobs/StagePage.scala#L850 > > 3.0 uses the formatDate js function on the same taskData.launchTime. so I think what you are saying is that formatting done there is not correct for the timezone handling? It is also putting it in UTC versus putting it in the local timezone? Thanks, We can see in branch-3，`launchTime ` from jersey server in spark driver is correct, which will be converted to time string like`2020-06-25T14:50:49.779GMT`, then the formatDate in utils.js treat it as `date.split(".")[0].replace("T", " ");`, `2020-06-25T14:50:49.779GMT` will be converted to `2020-06-25 14:50:49.779`, but correct is `2020-06-25 22:50:49.779` in +8 timezone. ---------------------------------------------------------------- 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. For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
