Last modified: 2011-03-13 00:07:31 UTC
dir=older SELECT /* ApiQueryRecentChanges::run */ rc_timestamp,rc_namespace,rc_title,rc_cur_id,rc_type,rc_moved_to_ns,rc_moved_to_title,rc_deleted,rc_comment,rc_user,rc_user_text,rc_old_len,rc_new_len,rc_logid,rc_log_type,rc_log_action,rc_params FROM `mw_recentchanges` FORCE INDEX (rc_timestamp) WHERE (rc_timestamp<='20110214043434') AND (rc_timestamp>='20110215043434') AND rc_deleted = '0' AND (rc_bot = 0) ORDER BY rc_timestamp DESC LIMIT 11 dir=newer SELECT /* ApiQueryRecentChanges::run */ rc_timestamp,rc_namespace,rc_title,rc_cur_id,rc_type,rc_moved_to_ns,rc_moved_to_title,rc_deleted,rc_comment,rc_user,rc_user_text,rc_old_len,rc_new_len,rc_logid,rc_log_type,rc_log_action,rc_params FROM `mw_recentchanges` FORCE INDEX (rc_timestamp) WHERE (rc_timestamp>='20110214043434') AND (rc_timestamp<='20110225043434') AND rc_deleted = '0' AND (rc_bot = 0) ORDER BY rc_timestamp LIMIT 11 You can quite clearly see the older is trying to do less than a date, and then greater than a date in the future. No good! Seems to be evident back to 1.16 at least (if not before). Tested locally and on enwiki
api.php?action=query&list=recentchanges&format=xmlfm&rcprop=timestamp|user|title|sizes|loginfo|comment&rcshow=!bot&rcstart=2011-02-25T04:34:34Z&rcend=2011-02-14T04:34:34Z&rcdir=newer api.php?action=query&list=recentchanges&format=xmlfm&rcprop=timestamp|user|title|sizes|loginfo|comment&rcshow=!bot&rcstart=2011-02-25T04:34:34Z&rcend=2011-02-14T04:34:34Z&rcdir=older But works if you swap the start and end around... http://192.168.0.190/w/api.php?action=query&list=recentchanges&format=xmlfm&rcprop=timestamp|user|title|sizes|loginfo|comment&rcshow=!bot&rcstart=2011-02-25T04:34:34Z&rcend=2011-02-14T04:34:34Z&rcdir=older I'm struggling to decide whether this is a broken user model, or something the api should be more smart about..
<spaceturtle> I just expected to be able to put a start date/time and an end date/time and have it work <Danny_B|backup> why is geshi css now loaded within the page and not linked as external stylesheet? <Reedy> Like I say, I'm not sure if this is something the api should really fix <Reedy> spaceturtle, exactly, the api doesn't match the expected user model /api.php?action=query&list=recentchanges&format=xml&rclimit=500&rcprop=timestamp|user|title|sizes|loginfo|comment&rcshow=!bot&rcend=2011-02-14T04:34:34Z&rcstart=2011-02-15T04:34:34Z&dir=newer <Reedy> spaceturtle, the more i think about it, the more i get confused, but thinking it should be smarter about it <Reedy> it should just do it between the 2 specified dates, and then order them based on older/newer <Reedy> IMHO <Reedy> Except when only one provided, then it can just do it >= or <= given value, based on direction <spaceturtle> Reedy: I agree with you 100% <spaceturtle> Reedy: I am still trying to get my queries right and it is a real pain <spaceturtle> I can't imagine someone trying to do this without access to #mw
if I understand correctly the api is just fine like the documentation says: http://www.mediawiki.org/wiki/API:Recentchanges rcdir: Direction to list in * older: List newest changes first (default). Note: rcstart has to be later than rcend. * newer: List oldest changes first. Note: rcstart has to be before rcend. Tools like RTRC and LiveChanges use these start/end and rcdir parameters en mass and work without issues, all via the API, since 1.16 and work in 1.17 as well. Marking invalid, please reopen if I misundestood.
Per IRC, repurposing bug. I didn't even bother to check the onwiki documentation, which is clearer per Krinkle. Multiple usages of dir with timestamp <Reedy> Krinkle, i didn't bother looking at the onwiki documentation. Might be worth just taking that and putting it on all the auto generated info <Krinkle> Reedy: I didn't look at the auto generated one, I presumed it would be there too ? <Reedy> Nope, it's not <Reedy> rcdir - In which direction to enumerate <Reedy> One value: newer, older <Reedy> Default: older <Krinkle> afaik it makes sense though, it doesnt' say 'past' or 'now' it says 'start' 'end' which are relativee. <Krinkle> so it makes sense, but it's not obvious since there's multiple interpretations possible. Maybe refactor out to reduce duplication. Easier to normalise across the board
Half fixed in r83797, need to do (asc|desc)(ending)?
r83799
