Correct that ElapsedTime() never resets to zero?

[Oso]

Am I correct in saying that ElapsedTime() never resets during a running process, unless it exceeds the limit of the variable? In other words, it represents the period of time in milliseconds that the process has been running?

When I wrote the below timer code some weeks ago, I deliberately tested if ElapsedMilliseconds() has cycled back round to zero, which I think I've done correctly (first conditional statement). But just thinking about it properly now, if the limit of 64-bit integer is 9,223,372,036,854,775,807 then divided by the number of milliseconds in a day, that would be 1,067,519 days.

Just wanted to check really, is there any way that ElapsedMilliseconds() could be reset, that I'm not aware of?

Code: Select all

    ; **
    ; ** Perform periodic reconnection attempts
    ; **
    timernow.i = ElapsedMilliseconds()                                  ; Time now
    If timernow.i < timerlast.i                                         ; Deal with ElapsedMilliseconds() time having reset back to zero
      timerlast.i = 0                                                   ; Reset the last time to deal with this case
    EndIf
    If timernow.i > timerlast + timerint.i                              ; Check for elapsed interval period 
      timerlast.i = timernow.i                                          ; Set the last time to now

[mk-soft]

No,

A performance timer is started the first time it is used. To get a new starting point you have to buffer the current value.

[Oso]

No, A performance timer is started the first time it is used. To get a new starting point you have to buffer the current value.

Great, that's fine then, thanks for that. I seem to remember testing this code some weeks ago but I'm not sure how I did it! I think I must have added a fake time to it, to exceed the limit. Anyway, I don't think anyone's computer is going to run continuously for 1 million days.

[mk-soft]

An overflow should also not be a problem as the quad time is defined as Signed. This means that the difference is always correct when calculating with overflow, as long as the difference fits in a quad

Code: Select all

Global time.q, lasttime, diff.q

; Simulate high time
time = $7FFFFFFFFFFFFFFF - 200

lasttime = time
For i = 1 To 10
  time + 40
  diff = time - lasttime
  Debug "" + time + " - " + diff
  lasttime = time
Next

----

This is also not a fault if an overflow occurs. Therefore, you must always make sure that your own calculations fit into the variable type.

Code: Select all

;- Addition with overflow check

Procedure addLongOvf(*result.long, a.l, b.l)
  *result\l = a + b;
  If(a > 0 And b > 0 And *result\l < 0)
    ProcedureReturn -1;
  EndIf
  If(a < 0 And b < 0 And *result\l > 0)
    ProcedureReturn -1;
  EndIf
  ProcedureReturn 0 ;
EndProcedure

Define a.l
Define b.l
Define c.l

a.l = $7FFFFFFF - 10
b.l = 20
r1 = addLongOvf(@c, a, b)
If r1
  Debug "Overflow"
EndIf
Debug c

a.l = $80000000 + 10
b.l = -20
r1 = addLongOvf(@c, a, b)
If r1
  Debug "Overflow"
EndIf
Debug c

[Oso]

An overflow should also not be a problem as the quad time is defined as Signed. This means that the difference is always correct when calculating with overflow, as long as the difference fits in a quad

Ah yes, I see. It's perpetual then, excellent.

[juergenkulow]

After more than 100000 years of program runtime (3551548724241346 ms), an overflow to -3551548724241346 would occur on my Windows.

[jacdelad]

So after about 200000 years it should be zero again.

[Demivec]

So after about 200000 years it should be zero again.

So that could lead to a Y.2M type of bug?

[juergenkulow]

If:

Code: Select all

Debug Date(2039,1,1,0,0,0)
;-1

Then any question about overflows is very justified.
By the way: 225238 years