[jira] Created: (LANG-478) StopWatch does not resist to system time changes

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

[jira] Created: (LANG-478) StopWatch does not resist to system time changes

JIRA jira@apache.org
StopWatch does not resist to system time changes
------------------------------------------------

                 Key: LANG-478
                 URL: https://issues.apache.org/jira/browse/LANG-478
             Project: Commons Lang
          Issue Type: Bug
    Affects Versions: 2.3
         Environment: all operating systems.
            Reporter: Regis Desgroppes


org.apache.commons.lang.time.StopWatch seems to be relying on wall clock, i.e. by calling java.lang.System.currentTimeMillis() to sample current time.

When a system time change occurs (user action, NTP synchronization...) between 2 calls to StopWatch.getTime(), the difference between the 2 samples is wrong: the measured duration may noticeably differ from the real one. Moreover, if the system time change consists in a backward adjustment, the difference may be negative.

In order to make StopWatch resistant to system time changes, would it be possible to use the process time, i.e. by making implementation calling java.lang.System.nanoTime() -multiplied by 1000, of course-.

Thanks a lot,
Regis.


--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply | Threaded
Open this post in threaded view
|

[jira] Updated: (LANG-478) StopWatch does not resist to system time changes

JIRA jira@apache.org

     [ https://issues.apache.org/jira/browse/LANG-478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Regis Desgroppes updated LANG-478:
----------------------------------

    Description:
org.apache.commons.lang.time.StopWatch seems to be relying on wall clock, i.e. by calling java.lang.System.currentTimeMillis() to sample current time.

When a system time change occurs (user action, NTP synchronization...) between 2 calls to StopWatch.getTime(), the difference between the 2 samples is wrong: the measured duration may noticeably differ from the real one. Moreover, if the system time change consists in a backward adjustment, the difference may be negative.

In order to make StopWatch resistant to system time changes, would it be possible to use the process time, i.e. by making implementation calling java.lang.System.nanoTime() -multiplied by 1000, of course.

Thanks a lot,
Regis.


  was:
org.apache.commons.lang.time.StopWatch seems to be relying on wall clock, i.e. by calling java.lang.System.currentTimeMillis() to sample current time.

When a system time change occurs (user action, NTP synchronization...) between 2 calls to StopWatch.getTime(), the difference between the 2 samples is wrong: the measured duration may noticeably differ from the real one. Moreover, if the system time change consists in a backward adjustment, the difference may be negative.

In order to make StopWatch resistant to system time changes, would it be possible to use the process time, i.e. by making implementation calling java.lang.System.nanoTime() -multiplied by 1000, of course-.

Thanks a lot,
Regis.



> StopWatch does not resist to system time changes
> ------------------------------------------------
>
>                 Key: LANG-478
>                 URL: https://issues.apache.org/jira/browse/LANG-478
>             Project: Commons Lang
>          Issue Type: Bug
>    Affects Versions: 2.3
>         Environment: all operating systems.
>            Reporter: Regis Desgroppes
>
> org.apache.commons.lang.time.StopWatch seems to be relying on wall clock, i.e. by calling java.lang.System.currentTimeMillis() to sample current time.
> When a system time change occurs (user action, NTP synchronization...) between 2 calls to StopWatch.getTime(), the difference between the 2 samples is wrong: the measured duration may noticeably differ from the real one. Moreover, if the system time change consists in a backward adjustment, the difference may be negative.
> In order to make StopWatch resistant to system time changes, would it be possible to use the process time, i.e. by making implementation calling java.lang.System.nanoTime() -multiplied by 1000, of course.
> Thanks a lot,
> Regis.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply | Threaded
Open this post in threaded view
|

[jira] Updated: (LANG-478) StopWatch does not resist to system time changes

JIRA jira@apache.org
In reply to this post by JIRA jira@apache.org

     [ https://issues.apache.org/jira/browse/LANG-478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Regis Desgroppes updated LANG-478:
----------------------------------

    Description:
org.apache.commons.lang.time.StopWatch seems to be relying on wall clock, i.e. by calling java.lang.System.currentTimeMillis() to sample current time.

When a system time change occurs (user action, NTP synchronization...) between 2 calls to StopWatch.getTime(), the difference between the 2 samples is wrong: the measured duration may noticeably differ from the real one. Moreover, should the system time change consist in a backward adjustment, the difference could be negative.

In order to make StopWatch resistant to system time changes, would it be possible to use the process time, i.e. by making implementation calling java.lang.System.nanoTime() -multiplied by 1000, of course.

Thanks a lot,
Regis.


  was:
org.apache.commons.lang.time.StopWatch seems to be relying on wall clock, i.e. by calling java.lang.System.currentTimeMillis() to sample current time.

When a system time change occurs (user action, NTP synchronization...) between 2 calls to StopWatch.getTime(), the difference between the 2 samples is wrong: the measured duration may noticeably differ from the real one. Moreover, if the system time change consists in a backward adjustment, the difference may be negative.

In order to make StopWatch resistant to system time changes, would it be possible to use the process time, i.e. by making implementation calling java.lang.System.nanoTime() -multiplied by 1000, of course.

Thanks a lot,
Regis.



> StopWatch does not resist to system time changes
> ------------------------------------------------
>
>                 Key: LANG-478
>                 URL: https://issues.apache.org/jira/browse/LANG-478
>             Project: Commons Lang
>          Issue Type: Bug
>    Affects Versions: 2.3
>         Environment: all operating systems.
>            Reporter: Regis Desgroppes
>
> org.apache.commons.lang.time.StopWatch seems to be relying on wall clock, i.e. by calling java.lang.System.currentTimeMillis() to sample current time.
> When a system time change occurs (user action, NTP synchronization...) between 2 calls to StopWatch.getTime(), the difference between the 2 samples is wrong: the measured duration may noticeably differ from the real one. Moreover, should the system time change consist in a backward adjustment, the difference could be negative.
> In order to make StopWatch resistant to system time changes, would it be possible to use the process time, i.e. by making implementation calling java.lang.System.nanoTime() -multiplied by 1000, of course.
> Thanks a lot,
> Regis.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply | Threaded
Open this post in threaded view
|

[jira] Updated: (LANG-478) StopWatch does not resist to system time changes

JIRA jira@apache.org
In reply to this post by JIRA jira@apache.org

     [ https://issues.apache.org/jira/browse/LANG-478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Regis Desgroppes updated LANG-478:
----------------------------------

    Description:
org.apache.commons.lang.time.StopWatch seems to be relying on wall clock, i.e. by calling java.lang.System.currentTimeMillis() to sample current time.

When a system time change occurs (user action, NTP synchronization...) between 2 calls to StopWatch.getTime(), the difference between the 2 samples is wrong: the measured duration may noticeably differ from the real one. Moreover, should the system time change consist in a backward adjustment, the difference could be negative.

In order to make StopWatch resistant to system time changes, would it be possible to use the process time, i.e. by making implementation calling java.lang.System.nanoTime() -multiplied by appropriate factor, of course.

Thanks a lot,
Regis.


  was:
org.apache.commons.lang.time.StopWatch seems to be relying on wall clock, i.e. by calling java.lang.System.currentTimeMillis() to sample current time.

When a system time change occurs (user action, NTP synchronization...) between 2 calls to StopWatch.getTime(), the difference between the 2 samples is wrong: the measured duration may noticeably differ from the real one. Moreover, should the system time change consist in a backward adjustment, the difference could be negative.

In order to make StopWatch resistant to system time changes, would it be possible to use the process time, i.e. by making implementation calling java.lang.System.nanoTime() -multiplied by 1000, of course.

Thanks a lot,
Regis.



> StopWatch does not resist to system time changes
> ------------------------------------------------
>
>                 Key: LANG-478
>                 URL: https://issues.apache.org/jira/browse/LANG-478
>             Project: Commons Lang
>          Issue Type: Bug
>    Affects Versions: 2.3
>         Environment: all operating systems.
>            Reporter: Regis Desgroppes
>
> org.apache.commons.lang.time.StopWatch seems to be relying on wall clock, i.e. by calling java.lang.System.currentTimeMillis() to sample current time.
> When a system time change occurs (user action, NTP synchronization...) between 2 calls to StopWatch.getTime(), the difference between the 2 samples is wrong: the measured duration may noticeably differ from the real one. Moreover, should the system time change consist in a backward adjustment, the difference could be negative.
> In order to make StopWatch resistant to system time changes, would it be possible to use the process time, i.e. by making implementation calling java.lang.System.nanoTime() -multiplied by appropriate factor, of course.
> Thanks a lot,
> Regis.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply | Threaded
Open this post in threaded view
|

[jira] Updated: (LANG-478) StopWatch does not resist to system time changes

JIRA jira@apache.org
In reply to this post by JIRA jira@apache.org

     [ https://issues.apache.org/jira/browse/LANG-478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Henri Yandell updated LANG-478:
-------------------------------

    Fix Version/s: 3.0

Sounds good. We've wanted to do this once we're 1.5 dependent, which 3.0 will be.

> StopWatch does not resist to system time changes
> ------------------------------------------------
>
>                 Key: LANG-478
>                 URL: https://issues.apache.org/jira/browse/LANG-478
>             Project: Commons Lang
>          Issue Type: Bug
>    Affects Versions: 2.3
>         Environment: all operating systems.
>            Reporter: Regis Desgroppes
>             Fix For: 3.0
>
>
> org.apache.commons.lang.time.StopWatch seems to be relying on wall clock, i.e. by calling java.lang.System.currentTimeMillis() to sample current time.
> When a system time change occurs (user action, NTP synchronization...) between 2 calls to StopWatch.getTime(), the difference between the 2 samples is wrong: the measured duration may noticeably differ from the real one. Moreover, should the system time change consist in a backward adjustment, the difference could be negative.
> In order to make StopWatch resistant to system time changes, would it be possible to use the process time, i.e. by making implementation calling java.lang.System.nanoTime() -multiplied by appropriate factor, of course.
> Thanks a lot,
> Regis.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply | Threaded
Open this post in threaded view
|

[jira] Updated: (LANG-478) StopWatch does not resist to system time changes

JIRA jira@apache.org
In reply to this post by JIRA jira@apache.org

     [ https://issues.apache.org/jira/browse/LANG-478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Henri Yandell updated LANG-478:
-------------------------------

    Attachment: LANG-478.patch

Attaching patch to move to nanoTime.

> StopWatch does not resist to system time changes
> ------------------------------------------------
>
>                 Key: LANG-478
>                 URL: https://issues.apache.org/jira/browse/LANG-478
>             Project: Commons Lang
>          Issue Type: Bug
>    Affects Versions: 2.3
>         Environment: all operating systems.
>            Reporter: Regis Desgroppes
>             Fix For: 3.0
>
>         Attachments: LANG-478.patch
>
>
> org.apache.commons.lang.time.StopWatch seems to be relying on wall clock, i.e. by calling java.lang.System.currentTimeMillis() to sample current time.
> When a system time change occurs (user action, NTP synchronization...) between 2 calls to StopWatch.getTime(), the difference between the 2 samples is wrong: the measured duration may noticeably differ from the real one. Moreover, should the system time change consist in a backward adjustment, the difference could be negative.
> In order to make StopWatch resistant to system time changes, would it be possible to use the process time, i.e. by making implementation calling java.lang.System.nanoTime() -multiplied by appropriate factor, of course.
> Thanks a lot,
> Regis.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply | Threaded
Open this post in threaded view
|

[jira] Closed: (LANG-478) StopWatch does not resist to system time changes

JIRA jira@apache.org
In reply to this post by JIRA jira@apache.org

     [ https://issues.apache.org/jira/browse/LANG-478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Henri Yandell closed LANG-478.
------------------------------

    Resolution: Fixed

svn ci -m "Applying my patch from LANG-478 - moving StopWatch to using nanoTime under the hood. "

Sending        src/java/org/apache/commons/lang/time/StopWatch.java
Transmitting file data .
Committed revision 749114.

> StopWatch does not resist to system time changes
> ------------------------------------------------
>
>                 Key: LANG-478
>                 URL: https://issues.apache.org/jira/browse/LANG-478
>             Project: Commons Lang
>          Issue Type: Bug
>    Affects Versions: 2.3
>         Environment: all operating systems.
>            Reporter: Regis Desgroppes
>             Fix For: 3.0
>
>         Attachments: LANG-478.patch
>
>
> org.apache.commons.lang.time.StopWatch seems to be relying on wall clock, i.e. by calling java.lang.System.currentTimeMillis() to sample current time.
> When a system time change occurs (user action, NTP synchronization...) between 2 calls to StopWatch.getTime(), the difference between the 2 samples is wrong: the measured duration may noticeably differ from the real one. Moreover, should the system time change consist in a backward adjustment, the difference could be negative.
> In order to make StopWatch resistant to system time changes, would it be possible to use the process time, i.e. by making implementation calling java.lang.System.nanoTime() -multiplied by appropriate factor, of course.
> Thanks a lot,
> Regis.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.