Originally Posted By: Wims
Here is an illustration of the incorrect result that can be produced by such code:

Code:
//window -h @timestamp | var %a $asctime($calc($ctime + 60),nn) | .timer -ho $asctime(HH) $+ : $+ %a 1 0 .timera -ho 1000 0 aline @timestamp $!!timestampex $!(|) if ($timer(a).reps == 0) $!({) savebuf @timestamp timestamp.txt $!(|) window -c @timestamp $!(})
Note that in this case I made the alias timestampex returning $timestamp $+ : $+ %ms for the sake of that test (my $timestampfmt is [HH:nn:ss]). This code creates a timer executing on the top of the next minute (if my timestamp is 22:50:18, it executes at 22:51) and then create a high-res timer which will execute 1000 times as fast as possible, echoing the value of $timestampex, here are the result: https://pastebin.com/MH7Vq1Nq and line 128 you can read:
Quote:
[05:34:01]:990
[05:34:01]:6
[05:34:02]:21



This is because $ticks increments in 15ms or 16ms jumps - presumably because that is the rate of the windows timer currently used. So unless there is a way of using a higher resolution timer in windows, it is less of a bug and more of a feature.