News:

  • August 25, 2026, 12:12:45 AM

Login with username, password and session length

Author Topic: TimeStamp()  (Read 8651 times)

Mike Nash

  • Hero Member
  • *****
  • Posts: 652
TimeStamp()
« on: March 26, 2017, 08:14:56 PM »
In particular, TimeStamp(thousandths)

I see this is available in scripting and I would like to know if it is possible to get the time to more than the seconds elsewhere.

So how does TimeStamp get the sub-second values and can I get them also?

BACKSTORY

This gets back to wanting to use indexed arrays but not seeing a good way to use an indexed timer (the timers don't accumulate time while not "active") to check if a certain period of time has elapsed since the last "event" for each indexed value. SO if it has been 30 seconds since D[V0] was true I need to do SOMETHING, but T[V0] only accumulates while V0 is that value but I am incrementing V0 multiple times per second. This led to my saving $NOW+30 in D[V0+50] and comparing D[V0+50] against $NOW to determine if 30 seconds has elapsed. But seconds is the resolution (which is fine at the moment.)


BobO

  • Host Moderator
  • Hero Member
  • *****
  • Posts: 6172
  • Yes Pinky, Do-more will control the world!
Re: TimeStamp()
« Reply #1 on: March 27, 2017, 09:02:30 PM »
I meant to answer this, but wasn't at a computer to check something, then forgot it when I was. Old. ::)

The short answer is 'kinda'. The MATH function TICKms() returns a full DWORD millisecond value that rolls over at a bit over 49 days. If you did TICKms()%1000, it will match the timestamp value...for 49 days. I'm pretty sure that after that the modulus operation will diverge from the timestamp counter, since 4294967295‬ % 1000 = 295 and 0 % 1000 = 0.

I'm pretty sure that with a small bit of creativity you could create a relative millisecond timer from TICKms() that could give you what you want, but no, there is currently no direct access to that timestamp value. It could easily be added to MATH, but obviously wouldn't be available until the next DmD release.
"It has recently come to our attention that users spend 95% of their time using 5% of the available features. That might be relevant." -BobO

Mike Nash

  • Hero Member
  • *****
  • Posts: 652
Re: TimeStamp()
« Reply #2 on: March 27, 2017, 09:13:43 PM »
Thank you.

I don't actually need the resolution at this point, so the other options are just fine for this project. But who knows what tomorrow will bring? I think when I get a little time to play, I want to see how that works.

Controls Guy

  • Internal Dev
  • Hero Member
  • ****
  • Posts: 3626
  • Darth Ladder
Re: TimeStamp()
« Reply #3 on: March 27, 2017, 09:30:57 PM »
Fine resolution real time clocks are good, say for time stamping alarms to identify first-out in a cascade.   But, even as is, you can see how you could easily do it with what's there  now.
I retract my earlier statement that half of all politicians are crooks.  Half of all politicians are NOT crooks.  There.

Mike Nash

  • Hero Member
  • *****
  • Posts: 652
Re: TimeStamp()
« Reply #4 on: March 27, 2017, 09:55:39 PM »
I just used $UTC (DST21) since it wouldn't change if $SummerTime does and I can use $UTC >= D[V0] outside of a MATH instruction. It's not the easiest thing to glance at to see how much longer something will last, but it's not important that it be for this application. It doesn't even have to be accurate. It's the use as a "timer" when I need elapsed real world time, not instruction true time.

The TickmS() or TickuS() have to be in a MATH instruction, which is fine, but I can get IF crazy if I don't watch myself.