I have been using ticks for various functions including calculating elapsed time. After user presses start button, I calculate start time as follows (in 60th of a second):
StartTime = ticks
When the stop button is pressed, I calculate elapsed time as follows:
ElapsedTime = (ticks - StartTime)/60
Problem is, on a Windows server, it always displays a bogus elapsed time of 2147484 seconds. Please note that the elapsed time displays fine when run on a Desktop. Are ticks on a Windows server different? Should we avoid using ticks in web apps?
I am considering using a timer instead. I want to use tenth of second accuracy (period = 100). Is there a better way?
What are you trying to time that requires a tenth of a second accuracy? If you really need that then a web app may not be your best choice.
Remember that all code resides on the server - NOT in the users browser. So the event where you tell it to give you the time difference is traveling from the browser, through countless internet gateways, finally to your server, where ticks is run again. It will always be wrong to varying degrees depending on the current state of network traffic.
I would think that just using the new Date and getting the seconds difference between start and stop is good enough for most cases, no?
You opened up a separate can of worms that I didn’t want opened. So, just to keep the separate “accuracy in web apps” can closed, just assume I could get by with 1 second accuracy.
Are you saying it is better to use the new Date function than a webtimer? If so, please explain why. I converted to webtimer and I think it will work fine on the server (I haven’t tried redeploying yet). I don’t know if the Date function will work as expected on the server; I have never used the Date function before,
Any idea why ticks function doesn’t work on a Windows server? I can submit a feedback report if needed.
Is there a way to do it that works in user’s browser? It seems like it would be possible to code in Javascript but I would like to avoid that if possible.
I use ticks for other functions so I would rather not change every use of ticks if I don’t have to. That’s why I am looking for multiple answers at once. It seems to me if ticks can’t be made to work reliably on multiple types of server then it shouldn’t be used in web apps at all. Strange thing is that I believe ticks were working fine a few months ago.
I believe it’s a better solution than ticks, but mainly because I’ve never needed better than 1 second resolution. DateTime is absolute and depends on nothing else. Timers to determine duration have too many variables (remember I have a ‘timing’ app that does duration).
No idea. A feedback report is never a bad idea. Make sure to include a sample app that replicates the problem with instructions on what the target platform is.
Possibly but I’ve never attempted anything like that.
I use ticks for determining timing of methods but otherwise I almost never use it. 1 second resolution is always good enough. If you need better resolution than that you can also use the new framework xojo.core.date since it has microsecond resolution.
[quote=160723:@Ken Gish]I will submit a feedback case (unless someone tells me otherwise).
I am reading here that there should be a nanoseconds property for Date class but I’m not seeing it. I am using 2014 release 3.2. What am I missing?[/quote]
See http://developer.xojo.com/date for the new framework date instead. Also, look there for DateInterval which may prove valuable for elapsed.
Why doesn’t xojo.core.dateinterval include totalseconds? I think that would be much easier to work with for elapsed time. Am I missing something (again)? Should I use date.totalseconds instead?
xojo.core.dateinterval.seconds rolls back to 00 after 59. So, to get totalseconds with this function, I’d have to calculate totalseconds myself (like date.totalseconds).
I think I may have discovered the problem with ticks. I was declaring my variables as integer. From the manual:
“The Integer type is an alias to the platform’s native signed integer type. On 32-bit builds, this ends up being Int32 and on 64-bit builds this ends up being Int64.”
I am not sure what “32-bit builds” means. I can’t find it in build settings. The machine I am developing on is 64-bit Windows 7.
In any case, I believe Xojo was setting my variables declared as integer to int32 because of the result I was getting: 2147483.65 seconds. That number should look very familiar. It is the overflow (max value) for int32 (2,147,483,647) after dividing by 1000 and rounding to 2 decimal points (which is what I was doing in my calculation before displaying the elapsed time result)!
I am guessing that the overflow occurred because the server hasn’t been rebooted in a while. Ticks is a measure of time (in 1/60th of second increments) since the computer was started. I guess it is good practice to reboot the server once in a while.
So, unless specifying UInt64 and rebooting don’t fix the problem, I don’t think I need to file a feedback case.
[quote=161683:@Ken Gish]I think I may have discovered the problem with ticks. I was declaring my variables as integer. From the manual:
“The Integer type is an alias to the platform’s native signed integer type. On 32-bit builds, this ends up being Int32 and on 64-bit builds this ends up being Int64.”
I am not sure what “32-bit builds” means. I can’t find it in build settings. The machine I am developing on is 64-bit Windows 7.
In any case, I believe Xojo was setting my variables declared as integer to int32 because of the result I was getting: 2147483.65 seconds. That number should look very familiar. It is the overflow (max value) for int32 (2,147,483,647) after dividing by 1000 and rounding to 2 decimal points (which is what I was doing in my calculation before displaying the elapsed time result)!
I am guessing that the overflow occurred because the server hasn’t been rebooted in a while. Ticks is a measure of time (in 1/60th of second increments) since the computer was started. I guess it is good practice to reboot the server once in a while.
So, unless specifying UInt64 and rebooting don’t fix the problem, I don’t think I need to file a feedback case.[/quote]
Use a double instead of an integer. That should solve your issue without restarting the host (!). I don’t know how Xojo gathers ticks, though. If the bug is because Windows Server does not roll over the ticks and is stuck, then it is not a Xojo issue.
You may also create your own ticks by incrementing a module or window property in a 17 millisecond multiple timer.