Alastair, I would like to see a stop watch function, or a clock that starts and continues to run from a predetermined point in time -- Like set by a variable.
And while we are at it either in seconds and hundredths of a minute. AND then to access that running clock for calculation purposes. Ned Ritchie -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alastair Burr Sent: Sunday, November 21, 2004 12:14 AM To: RBG7-L Mailing List Subject: [RBG7-L] - Re: Time variable format Thanks, Albert, I agree there are ways around, but the simplicity of repeatedly adding an integer to a variable and having the result come back as a version of the TIME datatype or a TIME function that allows more than 24 hours if need be is the whole point. It's a "passing of time" or an "amount of time" expressed in hh:mm:ss "format" that, even when you have calculated the component (years, months,) days, hours, minutes, and seconds you still have to combine back into a text format remembering to put leaing zeros in front of any minutes and seconds less than 10 which the current ADDSEC/MIN/HOUR funtions do nicely. Just in case anybody else is following this thread and thoroughly confused by it all you can add any number of minutes or seconds with the appropriate function and get them converted into hh:mm:ss - and you are not limited to 60 of either. So 128 seconds with ADDSEC comes back as 0:02:08 if you start with 0:00:00. But if your starting point has already reached, say, 23:59:00 and you add 128 seconds you'll only get back 0:01:08. As far as I know the first 24 hours simply disappears because, quite correctly, there are not 25 hours in a day. All I'm suggesting is that the current functions must "know" to take off the appropriate number of 24 hours so, presumably, somewhere in their calculations they have the total time. It would be nice to have the ability to switch that subtraction off and return the result with an unlimited number of hours - 25:01:08 in the example above. And that, I think, is enough on the subject unless there's a mass of people who would like the suggestion formalised as an enhancement request. Regards, Alastair. ----- Original Message ----- From: "Albert Berry" <[EMAIL PROTECTED]> To: "RBG7-L Mailing List" <[EMAIL PROTECTED]> Sent: Sunday, November 21, 2004 2:37 AM Subject: [RBG7-L] - Re: Time variable format > Note the 3600 dividor. Divide again by 24 and you have days. If you keep using the INT() function, > I am sure you can come up with what you need. Don't forget that you can nest functions rather > deeply! > > --- Alastair Burr <[EMAIL PROTECTED]> wrote: > > > Umm, that's interesting, Albert. > > > > I'm not sure if I can use it in quite the way I would like but I'll check. > > > > What I'm really after is the ability to show time outside the 24 hour clock. > > > > Maybe that would be 2 days and 15 hours or just a number of hours/mins/secs > > but not linked to a specific date or time "period". > > > > So, maybe, 96 hours minus 20 hours would return either 3 days 4 hours or > > 76:00:00 > > > > To give a practical example, my database has song titles with their timings > > (where known). > > For most needs I can add up totals and come in under 24 hours with no > > problem. > > However, if I wanted to know how long it would take to listen to every song > > or even every song by an artist then the 24 hour limit could easily be > > breached. > > > > It's not the most important thing in the world as there are ways around but > > they're convoluted and, quite honestly, I'm too lazy if there's a quicker > > way - and the ADD... functions are a real favourite of mine. I fully > > understand the current 24 hour logic but it's not the only logic - if you > > see what I mean! > > > > Regards, > > Alastair. > > > > > > > > > > ----- Original Message ----- > > From: "Albert Berry" <[EMAIL PROTECTED]> > > To: "RBG7-L Mailing List" <[EMAIL PROTECTED]> > > Sent: Saturday, November 20, 2004 10:45 PM > > Subject: [RBG7-L] - Re: Time variable format > > > > > > > Alastair, if you subtract DATETIME from DATETIME, you will get a DOUBLE > > response of however many > > > hours there are in the days you need. (Date format is DD/MM/YYYY) > > > > > > R>SET VAR vd1 DATETIME = '01/11/04 08:30:00' > > > > > > R>SET VAR vd2 DATETIME = '04/11/04 08:45:00' > > > > > > R>set var v3 DOUBLE = ((.vd2 - .vd1)/3600) > > > > > > R>show v v% > > > Variable = Value Type > > > ------------------ ------------------------------ -------- > > > vd1 = 01/11/0004 8:30:00 DATETIME > > > vd2 = 04/11/0004 8:45:00 DATETIME > > > v3 = 72.25 DOUBLE > > > > > > > > > > > > --- Alastair Burr <[EMAIL PROTECTED]> wrote: > > > > > > > It was the 32 seconds, or whatever, that _didn't_ temp me to mention the > > 24 > > > > hour limit in the first place. > > > > > > > > I like the idea of 96 o'clock... and, even more, the fact that the table > > > > wont be ready for 3 1/2 days... > > > > > > > > Nevertheless, we do all say things like 48 hours or 96 hours, or > > whatever. > > > > There are ways around formatting the result of a number of hours (and > > > > minutes/seconds) over the 24 but it's a bit of a pain when the info must > > be > > > > there in the first place to be able to subtract the whole number of days > > and > > > > leave only the remaining "time". > > > > > > > > I did think about saying that a new function and/or data type might be > > > > needed but, sometimes, it's interesting to see what responses appear > > without > > > > any prompting. Unless a lot of people have the same problem - which I > > > > doubt - I can't imagine a new data type being considered but a switch of > > > > some sort on the "time" functions: default of zero or null = as is while > > 1 = > > > > overall number of hours (plus the remaining mm:ss) might be worth > > > > considering. > > > > > > > > Right back when I first started using v2.11 you could add/subtract times > > and > > > > get an integer result and, as you say, do the maths from that to get > > days as > > > > well as the time. The relatively recent addition of the ADD... functions > > are > > > > a really useful addition - especially if you're repetitively entering > > > > figures from the numeric keypad - but the limit of 24 hours needs to be > > > > taken care of if you're likely to breach it. > > > > > > > > Alternatively, an ADD function based on DateTime datatype in addition to > > the > > > > separate ones for Date and Time would overcome the current leap between > > > > 23:59:59 and 1 day 00:00:01? > > > > > > > > Regards, > > > > Alastair. > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > From: "Lawrence Lustig" <[EMAIL PROTECTED]> > > > > To: "RBG7-L Mailing List" <[EMAIL PROTECTED]> > > > > Sent: Saturday, November 20, 2004 4:33 PM > > > > Subject: [RBG7-L] - Re: Time variable format > > > > > > > > > > > > > > It's not often that I get "extremely clever approach" said about my > > > > methods > > > > > > <g> but there is one thing to watch out for and that is if the > > elapsed > > > > time > > > > > > is more that 24 hours! > > > > > > > > > > > > Actually, it would be nice if there was a way that the time > > fucntions > > > > > > allowed the hours part of the time to exceed 24. I often want to add > > up > > > > > > times and reach the 24 hour barrier when displaying the results. > > > > > > > > > > From the original poster's example using 32 seconds, I figured we > > could > > > > ignore > > > > > the possiblity of 24+ elapsed times. > > > > > > > > > > Ultimately, however, to express genuine time quantities in H:M:S > > format > > > > would > > > > > require a NEW data type. The existing TIME datatype could _not_ be > > > > expanded to > > > > > go over 24 hours -- that would allow invalid data in genuine time > > columns > > > > ("I'm > > > > > sorry sir, but our computer shows that your reservation was for 96 > > > > O'Clock, and > > > > > the table won't be ready for 3 1/2 days!"). > > > > > > > > > > In the meantime, you can calculate elapsed time in seconds and format > > it > > > > like > > > > > this: > > > > > > > > > > SET VAR vElapsed INT = (.vEndTime - .vStartTime) > > > > > > > > > > SET VAR vElapsedFmt TEXT = + > > > > > CTXT(INT(.vElapsed/3600)) + ':' + + > > > > > CTXT(INT(MOD(.vElapsed, 3600)/60)) + ":" + + > > > > > CTXT(MOD(MOD(.vElapsed, 3600), 60)) > > > > > > > > > > (I think, that's top-of-my-head) > > > > > -- > > > > > Larry > > > > > > > > > > > > > > > > > > > > > > ===== > > > Albert Berry > > > Management Consultant > > > RR2 - 1252 Ponderosa Drive > > > Sparwood BC, V0B 2G2 > > > Canada > > > (250) 425-5806 > > > (250) 425-7259 > > > (708) 575-3952 (fax) > > > [EMAIL PROTECTED] > > > > > > > > > > ===== > Albert Berry > Management Consultant > RR2 - 1252 Ponderosa Drive > Sparwood BC, V0B 2G2 > Canada > (250) 425-5806 > (250) 425-7259 > (708) 575-3952 (fax) > [EMAIL PROTECTED] >
