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

Reply via email to