[
https://issues.apache.org/jira/browse/SUREFIRE-1512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16429070#comment-16429070
]
Michael Osipov commented on SUREFIRE-1512:
------------------------------------------
[~tibor17], the Unix case is fine. The long will do. I assume that etime is
bound to UTC anyway, not dependend on clock changes. As for Windows, the
{{String}} is incomparable and you cannot simply drop the offset and compare.
You have to normalize to UTC first and then you can compare.
> ProcessInfo for Windows is prone to timezone offset changes
> -----------------------------------------------------------
>
> Key: SUREFIRE-1512
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1512
> Project: Maven Surefire
> Issue Type: Bug
> Affects Versions: 2.21.0
> Reporter: Julian Reschke
> Priority: Major
>
> For some reason, on one of my machines, the current DST offset changes
> between calls. See
> <https://issues.apache.org/jira/browse/SUREFIRE-1444?focusedCommentId=16428263&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16428263>.
> This will cause surefire to think the forked VM terminated, as the string
> compare of time stamps detects a change.
> It would be good if the comparison code would actually parse the string value
> into a DST/TZ agnostic value for comparison.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
