That's fair enough. I've written a little JavaScript function for this anyways that seems to work fairly quickly so I'll stick with using that.

bscSCORM <notifications@github.com> wrote:

>In xAPI.md:
>
>> @@ -1903,7 +1914,10 @@ Returns: 200 OK, [Statement Result](#retstmts) (See section 4.2 for details) > 			"context:instructor".</td> > 	</tr> > 	<tr><td>ascending</td><td>Boolean</td><td>False</td> > -		<td>If true, return results in ascending order of stored time</td> > +		<td>If true, return results in ascending order.</td> > +	</tr> > +	<tr><td>orderByTimestamp</td><td>Boolean</td><td>False</td> > +		<td>If true, return results ordered by timestamp rather than stored time</td> > 	</tr> 
>
>@garemoko this change seems to go against the purpose of the query API, at least as I see it.
>
>Before I get into why, here is what I see the purpose of the query API as: 
>
>"Allow other systems, such as reporting systems, to pull in statements from the LRS, and to do simple filtering to exclude statements they're not interested in." 
>
>I see it as an explicit non-goal for the API to serve as the back end of a reporting UI. To the extent it works, great. The API is a long way from doing a good job of being such a back-end, and I don't think this is a burden that should be placed on the LRS.
>
>Ordering by stored time, and the "since" parameter is done so that the a reporting system (or another LRS), etc can keep up to date efficiently. A system ordering by timestamp would not be able to reliably synchronize (as statements with old timestamps can always "appear". It would have to be running queries live against the LRS (a use case we have never set out to support). Additionally, consumers may not realize that they shouldn't cache data when pulling in timestamp order, which could lead to surprising behavior.
>
>So, I urge us to not include this flag.
>
>—
>Reply to this email directly or view it on GitHub.￼
>