Works with integers only.
Here's a method of doing the calculation - but it assumes that you alwats
have two digits following the "."
----- batch begins -------
[1]@echo off
[2]set yss=49.39
[3]set yes=54.57
[4]set yss=%yss:.=%
[5]set yes=%yes:.=%
[6]set /a yps=%yes%-%yss%
[7]echo proctime=%yps:~0,-2%.%yps:~-2%
------ batch ends --------
Lines start [number] - any lines not starting [number] have been wrapped
and should be rejoined. The [number] that starts the line should be removed
[2]set yss=09.39
[3]set yes=14.57
As billious pointed out set /a is integer operations only. But you can
calculate the difference using a conversion to integers (as already
posted) or a VBS aided script. For examples see e.g.
30} Can one calculate the difference between two times in a script?
61} How can one devise a command line calculator?
193214 Feb 16 2007 ftp://garbo.uwasa.fi/pc/link/tscmd.zip
tscmd43.zip Useful NT/2000/XP script tricks and tips, T.Salmi
All the best, Timo
--
Prof. Timo Salmi ftp & http://garbo.uwasa.fi/ archives 193.166.120.5
Department of Accounting and Business Finance ; University of Vaasa
mailto:t...@uwasa.fi <http://www.uwasa.fi/~ts/> ; FIN-65101, Finland
Timo's FAQ materials at http://www.uwasa.fi/~ts/http/tsfaq.html
[2]set yss=9.39
[3]set yes=14.57
works. The constraint was two digits after the decimal point,
not before it.
- Larry
> > [2]set yss=09.39
> > [3]set yes=14.57
>
> [2]set yss=9.39
> [3]set yes=14.57
>
> works. The constraint was two digits after the decimal point,
> not before it.
From the OP: I extracted two second value from time. For example,
endSec=54.57 and startSec=49.39.
I interpret this in the way, that the variables are obtained
from %time% by substring extraction. And then the result will
be 09.39 and not 9.39.
So
[6]set /a yps=%yes%-%yss%
schould be replaced by
[6]set /a yps=1%yes%-1%yss%
Since you are extracting the expressions for seconds from time
(I assume you mean the time command) how do you know that the seconds
will be from the same minute?
Consider these two strings from time (11.97 seconds difference)
The current time is: 14:47:53.23
The current time is: 14:48:05.20
I think you mean that you'd extract 53.23 as the start and 05.20
as the end time. The math won't work unless you consider the
differences in the minutes (and perhaps also the hours or in the
extreme, the day and year).
- Larry
> Since you are extracting the expressions for seconds from time
> (I assume you mean the time command) how do you know that the seconds
> will be from the same minute?
In a modulo 60 arithmetic this doesn't matter at all.
If you don't like negative results, add 60.
Perhaps I should have said "How do you know that the start and end
time will be within one minute of each other." ?
Consider
The current time is: 14:40:53.23 <-- start
The current time is: 14:48:05.20 <-- end
- Larry
You will still get the correct result in a modulo 60
arithmetik:
Seconds only:
05 - 53 = -48 = +12
Minutes + seconds:
48:05 - 40:53 = 07:12 = 432 = 12
-48, 12 and 432 are all the same value (mod 60).
You have the same effect with:
set /a x=3123456789-1
echo %x%
We have no information from the OP about the format that the times take.
Your example could be solved with
[6]set /a yps=1%yes%-1%yss%
but this would obviously fail if the start time did NOT have exactly the
same number of full-seconds digits as does the end-time.
It will also fail if the format doesn't have exactly two digits following
the "." - which may be the case if the part-seconds are "n0" and it might
even be that there may be no "." at all if the part-seconds is "00".
We simply don't know - and even if we assume that the digits are being
extracted from the TIME string, there is no compensation for turning over
the minute - that is, where the end-time seconds is less than the
start-time. We can't even simply add 60 arbitrarily, since there is no
guarantee that the end-time is less than 1 minute after the start. Perhaps
the elapsed-time being captured is expressed as seconds.hundredths
regardless of the time involved. Perhaps it is changed to
minutes:seconds.hundredths.
We can have no idea of how to make a foolproof solution without a complete
format description from the OP. It could even be that the elapsed-time in
question would exceed a day, or several days. Hundredths of a second would
seem somewhat irrelevant in this case, but we'd then need to get into
calendar-calculations with all the fun of formats...