Sorry that I'm late to the party here. In order to calculate the elapsed time you can just subtract the lower 4 bytes.

So if Start% is the lower four bytes of the start time & Finish% is the lower four bytes of the finish time:

TimeTaken% = Finish% - Start%

This "Just works" and will always produce the correct result even with rollovers.

If TimeTaken% < 0 then the finish was before the start.

Jeff

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 22 Apr in article
<69d8792f-18c1-4a2c-8e14-0a7e0fd698c7@googlegroups.com>,
<jeffrey.a.doggett@gmail.com> wrote:

Sorry that I'm late to the party here. In order to calculate the
elapsed time you can just subtract the lower 4 bytes.

So if Start% is the lower four bytes of the start time & Finish% is
the lower four bytes of the finish time:

TimeTaken% = Finish% - Start%

This "Just works" and will always produce the correct result even
with rollovers.

If TimeTaken% < 0 then the finish was before the start.

I don't think this works if the time difference is over 35 weeks....

--
Martin Avison
Note that unfortunately this email address will become invalid
without notice if (when) any spam is received.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thursday, 23 April 2020 00:09:59 UTC+1, Martin wrote:

On 22 Apr in article
<69d8792f-18c1-4a2c-8e14-0a7e0fd698c7@googlegroups.com>,
<jeffrey.a.doggett@gmail.com> wrote:

Sorry that I'm late to the party here. In order to calculate the
elapsed time you can just subtract the lower 4 bytes.

So if Start% is the lower four bytes of the start time & Finish% is
the lower four bytes of the finish time:

TimeTaken% = Finish% - Start%

This "Just works" and will always produce the correct result even
with rollovers.

If TimeTaken% < 0 then the finish was before the start.

I don't think this works if the time difference is over 35 weeks....

--
Martin Avison
Note that unfortunately this email address will become invalid
without notice if (when) any spam is received.

No, but Alan is timing a canoeist down a slalom course. If it takes 35 weeks then there's something amiss.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <5865cc4b9aNews03@avisoft.f9.co.uk>,
Martin <News03@avisoft.f9.co.uk> wrote:

Indeed. But what happens when the 5-byte hex times are...
start time = 58 00 00 04 00
end time = 57 00 00 05 00
gives x100 ... when it should be flagged as negative and duff!

I've already added a note in my programming library, but can we have a definitive answer on this, please!

An agreed one that I can save as a note!

John

--
John WILLIAMS, now back in the UK - no attachments to these addresses!
Non-RISC OS posters change user to johnrwilliams or put 'risc' in subject!
Who is John WILLIAMS? http://petit.four.free.fr/picindex/author/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 23 Apr in article
<dccbb754-a167-43b8-ad2f-f6d82fbbd68b@googlegroups.com>,
<jeffrey.a.doggett@gmail.com> wrote:

On Thursday, 23 April 2020 00:09:59 UTC+1, Martin wrote:

On 22 Apr in article <69d8792f-18c1-4a2c-8e14-0a7e0fd698c7@googlegroups.com>,
<jeffrey.a.doggett@gmail.com> wrote:

Sorry that I'm late to the party here. In order to calculate the
elapsed time you can just subtract the lower 4 bytes.

So if Start% is the lower four bytes of the start time &
Finish% is the lower four bytes of the finish time:

TimeTaken% = Finish% - Start%

This "Just works" and will always produce the correct result
even with rollovers.

If TimeTaken% < 0 then the finish was before the start.

I don't think this works if the time difference is over 35
weeks....

No, but Alan is timing a canoeist down a slalom course. If it
takes 35 weeks then there's something amiss.

Indeed. But what happens when the 5-byte hex times are...
start time = 58 00 00 04 00
end time = 57 00 00 05 00
gives x100 ... when it should be flagged as negative and duff!

--
Martin Avison
Note that unfortunately this email address will become invalid
without notice if (when) any spam is received.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Indeed. But what happens when the 5-byte hex times are...
start time = 58 00 00 04 00
end time = 57 00 00 05 00
gives x100 ... when it should be flagged as negative and duff!

That would require the judge on the finish line to press his button 35 weeks before the starter presses his button. Cannot happen.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In message <5865cc4b9aNews03@avisoft.f9.co.uk>
Martin <News03@avisoft.f9.co.uk> wrote:

On 23 Apr in article
<dccbb754-a167-43b8-ad2f-f6d82fbbd68b@googlegroups.com>,
<jeffrey.a.doggett@gmail.com> wrote:

On Thursday, 23 April 2020 00:09:59 UTC+1, Martin wrote:

On 22 Apr in article <69d8792f-18c1-4a2c-8e14-0a7e0fd698c7@googlegroups.com>,
<jeffrey.a.doggett@gmail.com> wrote:

Sorry that I'm late to the party here. In order to calculate the elapsed time you can just subtract the lower 4 bytes.

So if Start% is the lower four bytes of the start time & Finish% is
the lower four bytes of the finish time:

TimeTaken% = Finish% - Start%

This "Just works" and will always produce the correct result even
with rollovers.

If TimeTaken% < 0 then the finish was before the start.

I don't think this works if the time difference is over 35 weeks....

No, but Alan is timing a canoeist down a slalom course. If it takes 35 weeks then there's something amiss.

Indeed. But what happens when the 5-byte hex times are...
start time = 58 00 00 04 00
end time = 57 00 00 05 00 gives x100 ... when it should be flagged as negative and duff!

As has already been pointed out, the answers are all correct within a
certain range of times, something like 35 weeks, which is orders of
magnitude greater than can happen in this use case.

It's not a general solution, but it is entirely correct and appropriate
for what the OP's needs.

David

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 23 Apr in article
<6667d647-6873-488d-8a39-ed15086e185a@googlegroups.com>,
<jeffrey.a.doggett@gmail.com> wrote:

Indeed. But what happens when the 5-byte hex times are...
start time = 58 00 00 04 00
end time = 57 00 00 05 00
gives x100 ... when it should be flagged as negative and duff!

That would require the judge on the finish line to press his button
35 weeks before the starter presses his button. Cannot happen.

Unfortunately the OP in his first post said...

I need to reliably detect negative results, which can occur if a
spurious finish time pulse arrives before a start time.

--
Martin Avison
Note that unfortunately this email address will become invalid
without notice if (when) any spam is received.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In message <5865ded017News03@avisoft.f9.co.uk>
Martin <News03@avisoft.f9.co.uk> wrote:

On 23 Apr in article
<6667d647-6873-488d-8a39-ed15086e185a@googlegroups.com>,
<jeffrey.a.doggett@gmail.com> wrote:

Indeed. But what happens when the 5-byte hex times are...
start time = 58 00 00 04 00
end time = 57 00 00 05 00 gives x100 ... when it should be
flagged as negative and duff!

That would require the judge on the finish line to press his button 35 weeks before the starter presses his button. Cannot happen.

Unfortunately the OP in his first post said...

I need to reliably detect negative results, which can occur if a spurious finish time pulse arrives before a start time.

Still OK; it won't go wrong unless the spurious pulse arrives between
(roughly) 17 weeks and 35 weeks before the start time.

David

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)