[
https://issues.apache.org/jira/browse/SUREFIRE-1512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16429062#comment-16429062
]
Tibor Digana commented on SUREFIRE-1512:
----------------------------------------
[~reschke]
Regarding Windows we can make a workaround and take {{20180406142327.741074}}.
What use case is behind these two outcomes?
{code:bash}
> wmic process where "(ProcessId=11460)" get CreationDate
CreationDate
20180406142327.741074+120
{code}
{code:bash}
> wmic process where "(ProcessId=11460)" get CreationDate
CreationDate
20180406132327.741074+060
{code}
> 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)
