Hi friends
I am required to do some calculation on time to find the total time user spend on site.
addTime() in TimeObject
now the problem is that this code creating ambiguity in 1 or 10
as 1.4 or 1.40
i want to add preceding zero to solve this problem but don't know how to achieve that
Jeanne Boyarsky
,
author & internet detective
staff
I don't follow the problem. Are you saying that both "4" is getting stored in TimeObject regardless of whether you pass 4 or 40? Or that when you later display a time object, it isn't clear what you mean?
The problem is as per the code given above...
1.4 is 1.4 and 1.40 is 1.40 now problem is
1.4+1.4=1.8
1.40+1.40=1.80
now which is greater 1.8 or 1.80 it is creating ambiguity
so i want 1.4 as 1.04 but don't know how to achieve.
William Brogden
,
Author and all-around good cowpoke
If this was my problem I would just store the system time in milliseconds for start and end and convert to hours/min/sec format only as needed for display or formatting.
See the java.lang.System class, currentTimeMillis() method.
Please DontWriteLongLines. It makes your thread very hard to read. I've broken yours up this time, but for future reference, please remember:
80 characters max.
(the SSCCE page actually recommends 62)
And that includes method calls, string literals AND comments.
Thanks.
PS: It might also be worth mentioning that those extremely long method calls feature redundant SimpleDateFormat objects, and Date objects which also look redundant (and may actually be wrong).
One of the important things when writing timing methods is to ensure that the code affects the result of the timing as little as possible - note that this doesn't mean optimizing to the nth degree; more that the order in which things are done is very important.
You should also decide whether the overall timing should include the time taken to measure the timing or not.
Winston Gutkowski wrote:You should also decide whether the overall timing should include the time taken to measure the timing or not.
I don't think I quite agree with this. Let me see if I can figure out why...
It shouldn't take very long to measure the time taken to execute some code. A couple of calls to System.currentTimeMillis or something like that, we're talking a few nanoseconds. Whatever you're timing, it should run for a lot longer than that. If you try to time something which runs for only a millisecond, let's say, it's going to be subject to random things happening elsewhere in the system, which could be anything from optimizations happening in the hardware to the operating system deciding to install the latest version of your anti-virus. You should really be timing something which isn't subject to those variations. Something, in other words, which takes a significant length of time to run. And then that makes the measurement time insignificant.
Paul Clapham wrote:It shouldn't take very long to measure the time taken to execute some code. A couple of calls to System.currentTimeMillis or something like that, we're talking a few nanoseconds. Whatever you're timing, it should run for a lot longer than that.
True, and if the thing you're running takes very little time, you should run it a lot and then take probably an average or (slightly more difficult) a median.
However, if you're writing a generic timer, you can't be absolutely sure how your clients are going to use it, so it's probably worth making sure that the internal code is as correct as possible. I've written a nanosecond()-based Stopwatch class that tries as far as possible not to have its own code affect timing, so the establishment of start time is the last statement in its start() method and determination of stop time is the first statement in stop().
That's all I'm saying. It doesn't take rocket science; just a little care. It could still possibly be affected by compiler optimization, but at least I've done my bit.
Winston
Post by:autobot
Just let me do the talking. Ahem ... so ... you see ... we have this tiny ad...
a bit of art, as a gift, that will fit in a stocking