well, that comes mainly with trial and error. The wait command isn't always an exact amount of time either, but from a few tests you can figure it out for yourself.
First open up /cg_drawtimer 1 to give yourself an internal game clock to measure by. Then get a demo that's long enough to test on and set it as the demo to play in the script (we'll call the demo 'test'). set timescale to 100 and wait to 100 and then play the demo. Watch the timer on the top right of the demo when it stops fast forwarding to see how much time 100 waits represented. You can try it with say 200 waits to see if you get the same ratio.
Ok so here's the more visual way to see it:
1. /cg_drawtimer 1
2. name demo: test
3. turn on cheats (/devmap ffa_yavin then return back to main menu)
4. run script and watch timer at end
Script would look like this:
demo test;timescale 100;wait 100;timescale 1
to figure out how many waits per minute you can take the ending timer and convert it into a real minute number. Say at timescale 100, 100 waits got us to time 3:24. That's 3.4 minutes (took 3 minutes + (24/60) = 3.4). So do k = waits/minutes (where k is the constant for waits/minute). So in this case k = 100/3.4. So our constant is 29.41 waits/minute. Now you can take this and figure out how many waits you need for any time in your demos.
For example, you want to get to time 14:30 in the demo. Convert it to 14.5 minutes. Then do 29.41 = waits/14.5; w = 426 waits. At timescale 100, 426 waits will get us to the time 14:30 in the demo.
Thing is it can take a long time for 426 waits to happen so there's a really easy way to make it faster. Since timescale and amount of waits is proportional you can double one and half the other and get to the same instant in the demo.
To get to the point 14:30 faster. Double the timescale to 200 and half the amount of waits to 218. If you want it even faster you can do timescale 400 waits 109 etc.
Welp, that's about the end of my thread-turned algebra class. Class dismissed