Skip Menu |

This queue is for tickets about the MediaWiki-API CPAN distribution.

Report information
The Basics
Id: 66611
Status: rejected
Priority: 0/
Queue: MediaWiki-API

People
Owner: Nobody in particular
Requestors: dan.bolser [...] gmail.com
Cc:
AdminCc:

Bug Information
Severity: Normal
Broken in: 0.35
Fixed in: (no value)



Subject: Recentchanges query fails with some valid rcstart formats
When doing a recent changes query, the rcstart parameter must be in epoch format (even though a variety of formats are supported by the API), else a 'bad' query URL may be generated. See: http://www.mediawiki.org/wiki/API:Recentchanges#Parameters and http://www.mediawiki.org/wiki/API:Data_formats#Timestamps My call looks like this: my $rc_list = $mw-> list ({ action => 'query', list => 'recentchanges', ## Get changes since: rcdir => 'newer', rcstart => $rcstart, ## Number of revisions to collect in each batch of results ## returned by the API rclimit => '500', ## Filters: rcshow => '!minor|!bot', #For reference #rctype => 'edit|new|log', #rcexcludeuser => '', ## Properties to return. See: ## http://www.mediawiki.org/wiki/API:Recentchanges rcprop => 'user|timestamp|title|flags|loginfo' }, { ## MW::API Config ## Max number of batches to collect (for debugging) #max => 1 } );
You don't actually provide any format example that doesn't work, making this bug report pretty useless. Please provide a real example.
From: dan.bolser [...] gmail.com
On Tue Mar 15 21:19:55 2011, exobuzz wrote: Show quoted text
> You don't actually provide any format example that doesn't work, making > this bug report pretty useless. Please provide a real example.
Sorry dude, seems I only half remembered the bug too... Below is code (and examples) that shows the problem using two different (but valid [1]) time formats... Namely, both queries work without throwing an error, but only one returns any values... It would be nice to try both queries directly in the API using a browser ... ;-P [1] http://www.mediawiki.org/wiki/API:Data_formats#Timestamps #!/usr/bin/perl -w use strict; use MediaWiki::API; use DateTime; my $start_iso = DateTime->now->subtract( hours => 3 )->iso8601; my $start_epoch = DateTime->now->subtract( hours => 3 )->epoch; print "$start_iso\n"; # 2011-03-16T12:58:40 print "$start_epoch\n"; # 1300280320 my $api = MediaWiki::API-> new({ api_url => "http://www.mediawiki.org/w/api.php" }); my $list_iso = $api->list({ action => "query", list => "recentchanges", rcdir => "newer", rcstart => $start_iso, }) ## Fool me once, shame on you. Fool me twice ... Well ... ## You can't fool me twice!! || die $api->{error}->{code}, ": ", $api->{error}->{details}; my $list_epoch = $api->list({ action => "query", list => "recentchanges", rcdir => "newer", rcstart => $start_epoch, }) ## Fool me once, shame on you. Fool me twice ... Well ... ## You can't fool me twice!! || die $api->{error}->{code}, ": ", $api->{error}->{details}; print scalar @$list_iso, "\n"; # Always returns 0 print scalar @$list_epoch, "\n"; # Returns the number of edits in the # last three hours (Sorry for filing such crappy bug reports, hopefully this gives you something to work with, but just let me know what else I can do). Dan.
for a iso8601 time as UTC mediawiki expects it to have a Z on the end. adding a Z to the end fixes it for your code. You might want to check with datetime module documentation about this in regards to compatibility. This isn't a mediawiki::api bug though - I just pass the values on to mediawiki.
From: dan.bolser [...] gmail.com
On Wed Mar 16 15:14:40 2011, exobuzz wrote: Show quoted text
> for a iso8601 time as UTC mediawiki expects it to have a Z on the end. > adding a Z to the end fixes it for your code. You might want to check > with datetime module documentation about this in regards to compatibility. > > This isn't a mediawiki::api bug though - I just pass the values on to > mediawiki.
Really sorry about that, I was sure I had tested this by adding the Z and thought I had seen the same error (so much so I just tested it again, but I see you are right!). I thought the value was perhaps not being correctly urlencoded by the API. Thanks for patience with these issues! Dan.