1. RE: Time conversion...
Hello again "LEVIATHAN",
heres some code to convert seconds to hours:minutes:seconds
and a demo...
include get.e
atom ink
function secs_To_hours_mins_secs_string(atom sec)
integer hour,min,minA,secA
secA=floor(sec+.5) --round seconds
sec=remainder(secA,60)
minA=(secA-sec)/60
min=remainder(minA,60)
hour=(minA-min)/60
return sprintf("%04d",hour)& --modify "%04d" for your own use
":"&sprintf("%02d",min)&
":"&sprintf("%02d",sec)
end function
--demo:
atom sec
sequence minsec
sec=19234.5 --for example
minsec=secs_To_hours_mins_secs_string(sec)
printf(1,"%s\n",{minsec})
ink=wait_key()
Good luck with it.
--Al
2. RE: Time conversion...
Hi again "LEV",
leviathan at uswest.net wrote:
> Whoa, wow, okay... I'm very impressed :)
>
> Clearly the tightest fuction here was Jiris secs2mins function, blew
> my
> mind away when I saw that all the fuctions that did it came out to do
> all
> the same thing :) And look what it took me! Too many lines of code!
> Whee!
>
> Anyway, thanx everyone for contributing, can we stick this into the
> EuSLP? (Eu Standard Libraries Project?)
>
> Thanx all,
>
> --"LEVIATHAN"
>
>
In my opinion, if your going to wrap a time function like that
you should go all the way and include hours as well, in case
someone inputs a high number for the seconds parameter. This
way you get the output
05:02:03 {hours:mins:secs}
for an input of
5*60*60 + 2*60 + 3
instead of an output of
302:03 {mins:secs}
Secondly,
using an integer as input parameter means the user has to
round the seconds input themselves. Rounding within the
function (passing atom) means you can get
119.99 seconds
to come out as
00:02:00 {hours:mins:seconds}
without bothering the user with this detail.
The shortest function isnt always the best, as the most versatile
functions are almost always longer then any others and are more
suited to inclusion into a library.
Consider a second parameter, that specifies whether or not to
output
hours:mins:secs
or just
mins:secs
or even
days:hours:mins:secs
or even several other formats to cover many possible applications.
Good luck with it.
--Al
3. RE: Time conversion...
On 26 Feb 2001, at 6:23, Al Getz wrote:
> Hi again "LEV",
>
> leviathan at uswest.net wrote:
> > Whoa, wow, okay... I'm very impressed :)
> >
> > Clearly the tightest fuction here was Jiris secs2mins function, blew
> > my
> > mind away when I saw that all the fuctions that did it came out to do
> > all
> > the same thing :) And look what it took me! Too many lines of code!
> > Whee!
> >
> > Anyway, thanx everyone for contributing, can we stick this into the
> > EuSLP? (Eu Standard Libraries Project?)
> >
> > Thanx all,
> >
> > --"LEVIATHAN"
> >
> >
>
> In my opinion, if your going to wrap a time function like that
> you should go all the way and include hours as well, in case
> someone inputs a high number for the seconds parameter. This
> way you get the output
> 05:02:03 {hours:mins:secs}
> for an input of
> 5*60*60 + 2*60 + 3
> instead of an output of
> 302:03 {mins:secs}
>
> Secondly,
> using an integer as input parameter means the user has to
> round the seconds input themselves. Rounding within the
> function (passing atom) means you can get
> 119.99 seconds
> to come out as
> 00:02:00 {hours:mins:seconds}
> without bothering the user with this detail.
>
> The shortest function isnt always the best, as the most versatile
> functions are almost always longer then any others and are more
> suited to inclusion into a library.
> Consider a second parameter, that specifies whether or not to
> output
> hours:mins:secs
> or just
> mins:secs
> or even
> days:hours:mins:secs
> or even several other formats to cover many possible applications.
Yeas, the "standard" usa time/date formats are not "standard" in the rest of the
world.
And there is more than one calendar too. Different knowledge domains have
different
methods of tracking time as well.
Kat
4. RE: Time conversion...
- Posted by leviathan at uswest.net
Feb 26, 2001
-
Last edited Feb 27, 2001
> Hi again "LEV",
>
> In my opinion, if your going to wrap a time function like that
> you should go all the way and include hours as well, in case
> someone inputs a high number for the seconds parameter.
Or perhaps two routines to do it, one with hours, and one without?
Or even an entire time conversion routine? (Minutes into seconds,
hours+minutes into seconds, even perhaps msecs?)
This
> way you get the output
> 05:02:03 {hours:mins:secs}
> for an input of
> 5*60*60 + 2*60 + 3
> instead of an output of
> 302:03 {mins:secs}
>
For the program I'm working on, I only get things that are usually
below 60 minutes, and even ones above that, I don't bother with
anyway, because that'd be one big freaking MP3 file! :)
> Secondly,
> using an integer as input parameter means the user has to
> round the seconds input themselves. Rounding within the
> function (passing atom) means you can get
> 119.99 seconds
> to come out as
> 00:02:00 {hours:mins:seconds}
> without bothering the user with this detail.
>
Again, in my case, I don't come across decimal seconds, but again,
yeah, passing atoms instead of integers is a better idea.
> The shortest function isnt always the best, as the most versatile
> functions are almost always longer then any others and are more
> suited to inclusion into a library.
> Consider a second parameter, that specifies whether or not to
> output
> hours:mins:secs
> or just
> mins:secs
> or even
> days:hours:mins:secs
> or even several other formats to cover many possible applications.
>
Which is what I was just thinking about too :)
> Good luck with it.
Luckily, I found exactly what I needed, however, I know full well that
I'll need some stuff that manipulates time like that later on, so I
should just go and wrap some time functions :) (Perhaps after I
learn how to wrap dlls)
--"LEVIATHAN"
