Some previous times dropping by 1 second

For anyone who’s paying close attention, you may notice that some times reported on the leaderboard have dropped by 1 second today. Here’s why:

When you submit times, Webscorer stores a ridiculous level of precision—lots and lots of significant digits that are then rounded for display. However, precision is truly meaningless in any timing system other than fully automatic timing systems used in fancy track meets (which rely on a camera taking 1000 frames per second). With hand timing, such as we use in FLRC track meets and other races, the USATF regulations specify a particular rounding algorithm. Since we’re all doing our own hand timing for the FLRC Challenge, I felt that the leaderboard should encapsulate this algorithm—we really don’t want someone “winning” a race because their submitted time happened to be a half-second faster than the next person’s.

USATF Rule 165.7(a) states:

  1. (a) For all hand-timed races on the track, unless the time is an exact 0.1 second, the time shall be converted and recorded to the next longer 0.1 second, e.g., 10.11 shall be recorded as 10.2. For races partly or entirely outside the stadium, unless the time is an exact whole second, the time shall be converted and recorded to the next longer whole second, e.g., 2:09:44.3 shall be recorded as 2:09:45.

We’re concerned with that last sentence. In essence, it means that if there are any digits beyond the whole second in your time, it will be rounded up to the nearest whole second.

The problem I discovered and that @steve-desmond fixed today is that when you enter a time manually in Webscorer (rather than scanning with your phone’s camera) by starting and stopping the run and then editing it, you can (and should!) enter 0 for the tenths place, but Webscorer has actually recorded a more precise time behind the scenes. Webscorer rounds the more precise time for its display, but we didn’t realize that entering 16:17.0 could actually have been 16:17.0771 or the like, and our code was rounding that up to 16:17.1 and then up to 16:18.

Glad you asked? :slight_smile:

PS: And we’ll also be fixing the timestamp on results shortly; switching between Standard Time and Daylight Saving Time is truly annoying for computer code.

Thanks for the explanation! I was wondering about the rounding, but figured it was such a minor thing it wasn’t worth asking about.